[Discovery] Thứ tự ra đời ảnh hưởng như thế nào đến mỗi người?

Tinhte-gia-dinh-02.

Một số bậc cha mẹ cho rằng anh em trong gia đình thường có tính cách, khả năng, sở thích khác nhau phụ thuộc vào thứ tự ra đời của nó. Hơn nữa, một số người còn cho rằng thứ bậc anh em còn có ảnh hưởng tới sức khỏe, trí tuệ và đặc điểm tính cách của đứa trẻ. Vậy thật ra, thứ hạng trong gia đình ảnh hưởng như thế nào tới mỗi con người? Rất nhiều nghiên cứu đã được thực hiện nhằm lý giải bí ẩn này và các nhà khoa học đã phát hiện ra được một số mối tương quan thú vị nhưng cũng đầy tranh cãi.

Các nhà nghiên cứu nhìn nhận rằng, thứ bậc anh em là một lĩnh vực cực kỳ khó nghiên cứu và cũng vì thế, các kết luận vẫn còn gây nhiều tranh cãi cho đến ngày nay. Có rất nhiều yếu tố bên ngoài xoay quanh chủ đề này như tuổi của mỗi người trong gia đình, họ cách nhau bao nhiêu tuổi, gia đình đó có tổng cộng bao nhiêu đứa con, giới tính của mỗi đứa con, hoàn cảnh môi trường nuôi dưỡng và nhiều điều kiện kinh tế – xã hội khác. Thật sự, các nhân tố trên không dễ phân lập nhằm xác định ảnh hưởng của mỗi yếu tố tới thứ bậc anh em và từ đó, biết được tác động tới mỗi thành viên trong nhà.

Hồi năm 1983, 2 nhà nghiên cứu Cécile Ernst và Jules Angst đã thực hiện một nghiên cứu lớn, kéo dài từ năm 1946 đến năm 1980 nhằm tìm câu trả lời cho thắc mắc trên. Từ đó đến nay, nhiều nhà tâm lý học đã tối thiểu hóa vai trò và ảnh hưởng của thứ bậc anh em đối với mỗi cá nhân. Và một số ý kiến còn cho rằng nó không thật sự có ảnh hưởng đến mỗi người. Nhưng trong suốt 4 thập kỷ qua, nhiều nhà tâm lý học vẫn tiếp tục nghiên cứu chủ đề này và cho đến hiện tại, họ đã thu được một số phát hiện.

Thứ tự ra đời và tính cách

Tinhte-Alfred Adler.
Alfred Adler (1870 – 1937)

Alfred Adler (1870 – 1937), bác sĩ, chuyên gia tâm thần học, người sáng lập trường phái tâm lý học cá nhân, là một trong những nhà nghiên cứu đầu tiên sử dụng thứ tự anh em trong gia đình để đánh giá tâm lý khách hàng của ông. Và Frank Sulloway, giáo sư tâm lý học hiện đại thuộc Viện công nghệ Massachusetts (MIT) đã nghiêm túc kiểm chứng các tiếp cận của tiền bối Alfred Adler.

Trong cuốn sách “Born to Rebel” xuất bản năm 1996, Sulloway đã đề xuất 5 đặc điểm tính cách của mỗi cá nhân là sự cởi mở (openness), sự tận tâm (conscientiousness), sự dễ chịu (agreeableness), tính hướng ngoại (extraversion) và tâm lý bất ổn (neuroticism). Ông cho rằng, thứ tự ra đời có ảnh hưởng nhất định tới tất cả các đặc điểm này. Theo Sulloway, đứa con đầu lòng sẽ có sự vâng lời nhiều hơn, trong khi những đứa con tiếp theo trong gia đình thể hiện sáng tạo cao hơn và có xu hướng từ chối sự áp đặt. Ông còn phát hiện rằng những người có cùng thứ hạng trong gia đình sẽ có nhiều điểm chung hơn so với anh em của họ.

TInhte-photo-frank-bears.
Frank Sulloway, giáo sư tâm lý học hiện đại, người đã đề xuất 5 đặc điểm tính cách của con người và sức ảnh hưởng của thứ bậc ra đời với 5 đặc điểm này

Và những quan điểm trong cuốn sách của Sulloway đã nhận được nhiều ý kiến trái chiều, tạo nên các cuộc tranh cãi chưa có hồi kết. Giáo sư xã hội học Jeremy Freese đến từ Đại học Northwestern là 1 trong những người phản bác hướng tiếp cận của Sulloway và thậm chí ông còn cho rằng Sulloway đã làm giả dữ liệu. Tuy nhiên, cuốn sách của Sulloway đã khơi mào cho sự ra đời của hàng trăm nghiên cứu khác dựa trên quan điểm của Sulloway.

Hồi năm 2010, tiến sĩ xã hội học người Đức Daniel Eckstein cùng các đồng nghiệp đã tiến hành phân tích một cách đầy đủ nhằm kiểm chứng và hoàn thiện ý tưởng của Ernst và Angst. Dựa trên kết quả của hơn 200 nghiên cứu sẵn có, nhóm có thể thống kê được ảnh hưởng của thứ bậc anh em đến đặc điểm tính cách và phong cách sống của mỗi cá nhân. Họ phát hiện ra rằng một số đặc điểm tính cách có mối liên hệ chặt chẽ với thứ hạng ra đời.

Tinhte-200-nghien-cuu.
Thống kê 200 nghiên cứu về mối tương quan giữa tính cách cá nhân và thứ tự ra đời (Cột bên trái là đặc điểm tính cách với n là tần số xuất hiện trong 200 nghiên cứu và cột bên phải là vị trí xuát hiện trong nghiên cứu.)

Cụ thể, những đứa trẻ đầu lòngh có xu hướng đạt được những đạt được những kết quả và thành công cao hơn. Những người là con một trong già đình luôn khao khát đạt được thành tựu. Những đứa con giữa thường dễ gần gũi. Và cuối cùng là những đứa con út, thường hướng tới các giao tiếp trong cuộc sống xã hội. Bên dưới đây là bảng thống kê 200 nghiên cứu trong cơ sở dữ liệu của nhóm.

Dựa theo bảng thống kê trên, rõ ràng là có sự liên kết giữa thứ tự trong gia đình và đặc điểm cá nhân cũng như sở thích nghề nghiệp. Một nghiên cứu hồi năm 2001 cũng chỉ ra rằng những đứa trẻ sinh sau thường đi theo khuynh hướng nghệ thuật và các nghề có liên quan đến tính hướng ngoại. Trong khi đó, những đứa con một và con đầu lòng thường theo đuổi những gì thuộc về trí tuệ. Đồng thời, các nhà nghiên cứu không nói rằng đây là một vấn đề bẩm sinh hay di truyền. Họ cho rằng đây là kết quả bởi sự định hướng của cha mẹ.

Mặt khác, thứ tự sinh trong gia đình cũng ảnh hưởng tới tính cạnh tranh của con người. Các nhà nghiên cứu đã chỉ ra rằng những đứa con đầu lòng thường theo đuổi “mục tiêu làm chủ” (Mastery Goals). Nhà tâm lý Bernd Carette tại Đại học Gent cho rằng, có thể nguyên nhân của điều này là do những đứa con đầu lòng đã nhận được sự đối xử khác biệt của cha mẹ từ thời thơ ấu, do đó, chúng sẽ dùng chính các tiêu chuẩn do cha mẹ đặt ra để tự đánh giá năng lực của mình.

Thú vị hơn, thứ tự sinh còn ảnh hưởng tới cách mỗi cá nhân hướng ngoại. Một nghiên cứu hồi năm 2013 cho thấy con đầu lòng biểu hiện sự làm chủ nhiều hơn, trong khi những đứa con thứ có xu hướng chan hòa hơn khi hướng ngoại. Mặt khác, những đứa con đầu lòng sẽ ít bị chi phối và quyết đoán hơn so với con thứ. Các nhà nghiên cứu lập luận rằng có thể chế độ nuôi day nghiêm ngặt và khắ khe đối với con đầu lòng khiến những đứa trẻ này vâng lời hơn, và sẽ tham chiếu mối quan hệ đó vào cuộc sống xã hội khi lớn.

Những mâu thuẫn trong nghiên cứu vẫn tiếp diễn

Tinhte-gia-dinh-01.
Ảnh minh họa

Hồi năm 1998, các nhà khoa học Canada đã khảo sát 1022 hộ gia đình và phát hiện ra rằng những đứa con đầu lòng bảo thủ hơn, đạt được thành công nhiều hơn và cũng tận tâm hơn so với con thứ. Những đứa con thứ lại được đánh giá là phá cách hơn, phóng khoáng và dễ chịu hơn. Tuy nhiên, kết luận này vẫn chưa thật sự phổ quát do dựa trên các đánh giá từ chính những thành viên trong gia đình. Một nghiên cứu khác dựa trên đánh giá từ những người không thuộc gia đình như bạn bè, đồng nghiệp, họ hàng lại cho biết là không có sự khác biệt trong thứ bậc anh em.

Thật ra, sự mâu thuẫn trên không quá đáng ngạc nhiên. Một vấn đề tồn tại trong cả 2 nghiên cứu trên chính là việc đánh giá nhân cách 1 anh A nào đó sẽ khác nhau khi người đánh giá là cha mẹ, anh chị em, bạn bè,… Nguyên nhân là do trong quá trình sinh sống, mối quan hệ giữa anh A với những người này là khác nhau. Đồng thời, những người sống chung gia đình anh A sẽ kết luận về anh khác với những người khác. Do đó, các nhà khoa học lập luận rằng có thể thứ bậc anh em chỉ ảnh hưởng đến với cá nhân đó trong phạm vi gia đình, và tác động này không thể tham chiếu vượt khỏi phạm vi này.

Bên cạnh đó, một nghiên cứu còn kết luận rằng mối quan hệ anh em sẽ liên tục phát triển trong suốt đời người. Mối quan hệ này luôn được tiến triển một cách chủ động song song với những hoàn cảnh xã hội. Đây là những nhu cầu thay đổi do tác động của cạnh tranh xã hội lẫn nhu cầu sinh học trong cá nhân mỗi người.

Một số mối liên hệ tiêu biểu

Tinhte-gia-dinh-03.
Ảnh minh họa

Trí tuệ là khía cạnh đặc biệt gây tranh cãi nhiều nhất. Những người ủng hộ cho rằng những đứa con đầu lòng sẽ có điểm kiểm tra trí thông minh cao hơn. Một nguyên nhân được đưa ra là con đầu lòng nhận được sự chú ý và nguồn lực từ cha mẹ nhiều hơn. Nhà tâm lý học nổi tiếng Robert Zajonc (1923-2008)cho biết thêm rằng con đầu lòng còn thể hiện khả năng giao tiếp bằng lời nói tốt hơn so với con thứ. Nguyên nhân ông đưa ra là do con đầu tích lũy được ngôn ngữ người lớn từ sớm và nhiều hơn so với con thứ.

Một nguyên nhân khác là tình trạng kinh tế xã hội của gia đình. Gia đình càng nhỏ thì thời gian và nguồn lực từ cha mẹ càng được mang đến cho con cái nhiều hơn. Đồng thời, tuổi sinh con của người mẹ cũng có thể là một nhân tố. Những bà mẹ trẻ có xu hướng trình độ thấp, thu nhập thấp nhưng lại tạo ra gia đình đông con, từ đó dẫn tới nguồn lực dành cho con cái kém hơn.

Hồi năm 2009, một nghiên cứu dẫn đầu bởi nhà tâm lý học Timothy Hartshorne đã củng cố kết luận trước đó của Sulloway rằng người ta thường có nhiều điểm chung với ai đó cùng thứ bậc gia đình. Hơn nữa, mối quan hệ giữa 2 người nam – nữ có cùng thứ bậc sẽ lâu dài và lãng mạn hơn.

Về mặt sức khở, người ta cũng nhận thấy rằng con đầu lòng có khả năng hấp thụ đường kém hơn và có huyết áp vào ban ngày cao hơn con thứ. Đồng thời, con đầu lòng có nguy cơ mắc các bệnh về trao đổi chất và tim mạch cao hơn khi trưởng thành. Các nhà khoa học cho rằng nguyên nhân có thể do sự thay đổi vật lý trong cổ tử cung người mẹ trong lần mang thai đầu tiên.

Trên đây là những yếu tổ tiêu biểu thể hiện mối tương quan giữa thứ tự anh em và khía cạnh sinh học, cá nhân mỗi người. Bên cạnh đó, các nhà nghiên cứu đã chỉ ra rất nhiều mối tương quan khác xoay quanh chủ đề này. Đồng thời, các nghiên cứu khi công bố đều nhận được cả 2 luồng ý kiến trái chiều nhau và tranh cãi vẫn cứ thế tiếp tục. Hy vọng rằng các nhà nghiên cứu sẽ sớm cùng nhau giải quyết được vấn đề được xem như bí ẩn khoa học còn tồn đọng đến ngày nay. Hy vọng bài viết cung cấp được một số thông tin thú vị cho các bạn. Cám ơn đã theo dõi bài viết. Chúc vui vẻ.

[Discovery] Các bộ phim có cảnh xe hơi rượt đuổi nhau hay nhất

car-stunt (2). ​Trong các phim hành động thì cảnh xe cộ rượt nhau ào ào ngoài đường dường như không thể thiếu, hiện nay công nghệ CGI đã rất tiến bộ và người ta đã có thể dựng hoàn toàn những cảnh đó trên máy tính, tuy vậy việc sử dụng những chiếc xe thật cho các cảnh quay đó vẫn cho thước phim cảm giác đáng giá hơn, xem thật hơn. Mời các bạn điểm qua 10 cảnh ngoạn mục do các chiếc xe thật tham gia “diễn xuất” trong phim ảnh.

Captain America: The Winter Soldier
Đây được xem là một trong những cảnh quay ngoạn mục nhất trong phần 2 Captain America: Chiến Binh Mùa Đông, lúc Nick Fury đang tự lái chiếc SUV của mình và bị Bucky Barnes truy sát. Bucky sau đó chỉ cần “Đằng sau, quay!” là né được nguyên chiếc xe trờ tới, rất thú vị. Về sau Nick đã nhanh trí giả chết để điều tra âm mưu lũng đoạn tổ chức SHIELD của Hydra.

car-stunt (4).
Batman: The Dark Knight

Cảnh quay cho thấy đoạn rượt đuổi nghẹt thở giữa Người Dơi và Joker, lúc này Joker lái một chiếc container dài thoòng để chạy trốn, cuối cùng Batman phải hạ chiếc xe nhằm bắt sống Joker.

car-stunt (6).
The Blues Brothers

The Blues Brothers ra rạp năm 1980, trong phim có một cảnh tất cả xe cảnh đang truy đuổi trên đường không may gặp nạn, hàng chục chiếc xe trong nháy mắt trở thành sắt vụn sau màn nhào lộn trên không.

car-stunt (9).
Speed

Tốc Độ (1994) là một trong những phim hành động kinh điển, chắp cánh cho sự nghiệp diễn xuất của Keanu Reeves và Sandra Bullock. Trong phim Speed, Keanu vô vai cảnh sát trẻ Jack Traven vô tình phát hiện âm mưu đặt bom chiếc xe bus 50 chỗ của kẻ khủng bố. Có đoạn chiếc xe phải bay qua cây cầu đang thi công bị hụt khúc giữa.

car-stunt (5).
The Man With the Golden Gun (1974)

Đây là một trong những phim về Điệp viên 007 dưới sự diễn xuất của Roger Moore. Trong phim có cảnh chiếc xe màu đỏ của Bond bay qua cây cầu gỗ, trước khi đáp xuống bờ bên kia còn kịp lộn ngang một vòng đẹp mắt.

car-stunt (2).
Terminator 2: Judgment Day

Trong phim có cảnh robot T-1000 lái xe tải truy sát cậu nhóc John Conner, chiếc xe đâm sập thành cầu và phim thẳng xuống dòng kênh như muốn cán nát cậu bé.

car-stunt (1).
Death Proof

4 cô gái lái chiếc xe rong chơi, phiêu theo điệu nhạc mà không ngờ rằng chiếc xe đen đang canh sẵn.

car-stunt (3).
Mad Max

Chiếc mô tô bị Max truy đuổi không kịp né chiếc xe tải đi ngược chiều.

car-stunt (7).
The Bourne Identity

Huyền thoại Bourne và cảnh quay nghẹt thở khi bị hàng chục xe cảnh sát truy đuổi sát nút.

car-stunt (1).
Furious 6

Series phim Fast & Furious có rất nhiều cảnh rượt đuổi xe ấn tượng, dưới đây là vài cảnh trong đó.

[Discovery] 10 thông tin thú vị về ngày Giáng Sinh

Tinhte_Giang-Sinh-201403.
Ảnh minh họa. Một bạn trẻ yêu công nghệ dán da điện thoại và cài đặt hình nền hình cây thông để mừng ngày lễ Giáng Sinh.

Chúng ta đang sống trong không khí Giáng Sinh tràn ngập khắp mọi nơi. Đây là 1 trong những ngày lễ quan trọng trong năm, không chỉ đối với những người theo Đạo mà còn được đón nhận tại rất nhiều quốc gia trên thế giới. Để mừng ngày Thiên Chúa Giáng Sinh, người ta thường ngồi với nhau bên các bữa tiệc, tặng quà, hát mừng và dĩ nhiên là tham dự các buổi lễ kỷ niệm Công giáo. Trong không khí se lạnh mùa đông, chúng ta hãy cùng điểm qua một số thông tin thú vị xoay quanh ngày lễ này nhé.

1. Chọn ngày lễ Giáng Sinh

Tinhte-ngay-giang-sinh.

Vào những buổi ban đầu, Giáo hội Công giáo không tổ chức một bữa tiệc lớn để kỷ niệm ngày Giáng Sinh như hiện nay. Trên thực tế, Kinh Thánh Công Giáo cũng không thực sự đề cập đến thời điểm cụ thể Thiên Chúa ra đời. Các nhà sử học cho rằng Chúa ra đời vào mùa xuân nhằm phù hợp với đoạn Kinh Thánh ghi chép lại cảnh các mục đồng chăn thả gia súc. Theo ghi chép sử học, vào khoảng năm 200 sau công nguyên, các nhà thần học Alexandria đã chọn ngày 20 tháng 5 làm ngày lễ kỷ niệm Chúa Giáng Sinh. Mãi cho đến thế kỷ thứ 4, Giáo Hội Công Giáo đã quyết định công nhận sự kiện Giáng Sinh là một ngày lễ chính thức và Đức Giáo Hoàng Julius I đã chọn ngày 25/12 hàng năm làm ngày lễ mừng.

2. Ai đã phát minh bộ tượng trang trí Giáng Sinh?

Tinhte-tuong-Chua.

Thánh Phanxicô Assisi (Tiếng Ý là Francesco d’Assisi), còn gọi là Thánh Phanxicô khó khăn, là một tu sĩ Công Giáo sáng lập ra Dòng Phan Sinh. Giáo hội xem ông là thánh bổn mạng của loài vật, chim trời, môi trường và nước Ý. Ông là người đã dành suốt cuộc đời cho sứ mạng truyền giáo và được phong thánh vào năm 1228. Một thông tin khác ít người biết đến, ông là người đã phát minh ra bộ tượng miêu tả cảnh Thiên Chúa Giáng Sinh vào thế kỷ 13. Đây là bộ tượng hết sức phổ biến trong ngày lễ Giáng Sinh. Hầu như mọi hang đá được bày dọn, trang trí ngày nay đều có sự xuất hiện của bộ tượng này với Chúa Jesus hài đồng ở giữa, Đức Mẹ, Thánh Giuse,…

3. Nguồn gốc của truyền thống tặng quà quà, thiệp mừng,…

Tinhte-cay-thon-noel.

Tặng quà, gởi thiệp mừng, tiệc tùng và nhiều truyền thống Giáng Sinh đã xuất hiện từ lâu chứ không phải được hình thành gần đây. Nguồn gốc của điều này đến từ thời La Mã cổ đại. Khi đó, người ta trao đổi những thứ nói trên vào ngày mừng năm mới Strenae (đặt theo tên vị thần của những món quà năm mới). Ban đầu, Giáo hội Công giáo không chấp nhận thực hiện những điều này trong ngày Giáng Sinh, tuy nhiên những thói quen cũ đã ăn sâu vào người dân nên vẫn được chuyển sang áp dụng cho ngày Giáng Sinh.

4. Nguồn gốc của Xmas và Noel

Tinhte_Giang-Sinh-201405.

Các nhà nghiên cứu cho rằng trong quá trình chuyển ngữ, các học giả đã dùng chữ chi (ký hiệu là X) trong tiếng Hy Lạp để rút gọn chữ “Christ” (Chúa Jesus, trong tiếng Hy Lạp là Χριστός) và cuối cùng, chữ Christmas sẽ được rút gọn thành Xmass. Điều này có nét tương đồng với sự hình thành của ẩn số x trong toán học, các bạn có thêm xem thêm tại đây.

Theo từ điển Oxford, Noel là một từ Pháp cổ (Nouel). Từ này được viết trong tiếng Pháp hiện đại là Noel và được người Pháp dùng để chỉ ngày Giáng Sinh. Đồng thời, trong tiếng Pháp, người ta sẽ nói “Joyeux Noel” để chỉ “Merry Christmas” hay “Chúc mừng Giáng Sinh”.

5. “Jingle Bell” là bài hát đầu tiên trên vũ trụ

Tinhte-Gemini_6_7.

Vào ngày 16/12/1965, 2 phi hành gia Walter “Wally” Schirra Jr. và Thomas P. Stafford đang trên bay trên quỹ đạo của Trái Đất bằng tàu Gemini 6. Khi đó, họ đã tiếp cận với tàu Gemini 7 đang được điều khiển bởi Frank Borman and Jim Lovell. Đây là lần đầu tiên 2 con tàu không gian gặp gỡ và cách nhau vài mét trên quỹ đạo. Lúc đó, tàu Gemini 6 đang chuẩn bị trở về Trái Đất và họ tưởng đã gặp người ngoài hành tinh do cả 2 tàu đều không biết trước được tình huống này.

Sau đó, phi hành gia từ tàu Gemini 6 đã xác định kỹ hơn, ông nhận ra “vật thể” trước mặt có 1 mô đun chỉ huy với 8 mô đun nhỏ hơn ở phía trước và ông nhận ra đây cũng là 1 phi thuyền. Phi hành gia chỉ huy đang mặc một bộ đồ màu đỏ. Và ngay lập, Walter và Stafford đã dùng kèn harmonica và chuông lén mang theo từ Trái Đất để chơi bài “Jingle Bells”. Sự kiện chớp nhoáng này đã được ghi vào lịch sử ngành hàng không vũ trụ và “jingle Bell” trở thành bài hát đầu tiên được xướng lên trên không gian.

6. Cây thông Noel

Tinhte-qua-noel.

Trước khi Giáng Sinh trở thành ngày lễ Công Giáo chính thức, người Đức đã trang trí những cây xanh quanh nhà họ để đẩy lùi bóng tối và những ngày mùa đông ảm đạm. Khái niệm “Cây Giáng Sinh” xuất hiện tại Strasbourg vào khoảng thế kỷ 17 và bắt đầu được những người nhập cư gốc Đức mang tới Pennsylvania vào năm 1820. Khi nữ hoàng Victoria cưới hoàng tử Đức Albert vào năm 1840, ông đã mang truyền thống “Cây Giáng Sinh” du nhập vào nước Anh. 8 Năm sau đó, tờ báo tại Mỹ đầu tiên đã đăng tải hình ảnh những cây Giáng Sinh hoàng gia Anh và thế là không chỉ tại Pennsylvania mà cả nước Mỹ bắt đầu sử dụng hình tượng này vào ngày Giáng Sinh.

7. Ông già Noel

2668823_Tinhte_Giang-Sinh-201401.

Ông già Noel là một nhân vật dựa trên Thánh Nicholas, một vị Giám mục Nhà thờ Công giáo và được xem như vị thánh bảo trợ trẻ em. Ông ra đời vào thế kỷ thứ 3 (khoảng năm 270 sau CN) tại một ngôi làng thuộc Thổ Nhĩ Kỳ. Ông nổi tiếng qua việc bí mật tặng những món quà hoặc tiền cho người nghèo. Ngày nay, hình ảnh hiện đại của ông già Noel thường đi kèm với bộ trang phục màu đỏ, bộ râu bạc trắng, cưỡi xe trượt tuần lộc và mang theo túi quà đi phát cho trẻ em.

8. Những cây kẹo hình gậy

Tinhte_Giang-Sinh-201402.

Vào những năm 1800, một người làm kẹo tại bang Indiana, Mỹ muốn tạo nên một loại kẹo làm hình tượng trong ngày Giáng Sinh. Cuối cùng, ông đã nảy ra ý tưởng uốn cong 1 thanh kẹo màu trắng thành hình dạng cây gậy. Đồng thời, ông thêm những đường màu đỏ xoay quanh cây kẹo để diễn tả tình yêu và sự hy sinh của Chúa Jesus cho nhân loại. Đầu tiên, ông dùng 1 mảnh kẹo bạc hà màu trắng, phẳng. Màu trắng biểu trưng cho sự tinh tuyền và vô nhiễm nguyên tội của chúa Jesus. Sau đó, ông cho thêm 3 sọc đỏ vào để tượng trưng cho sự đau đớn mà Chúa phải chịu khi Người chết trên thập giá.

Tiếp theo, mảnh kẹo được làm thêm 2 sọc đỏ đậm để biểu thị cho máu của Chúa đã chảy ra vì nhân loại. Và cuối cùng, toàn bộ sẽ được cuốn lại, cắt ngắn thành dạng thẳng và uốn cong 1 đầu theo hình cây gậy. Đây là biểu tượng cho cây gậy mà người chăn chiên dùng để chăn dắt bầy chiên của họ. Và nếu bạn đảo ngược cây gậy lên, nó sẽ trở thành chữ J, nghĩa là Jesus. Và dần dần, loại kẹo này bắt đầu được sử dụng rộng rãi như một trong những biểu tượng của ngày Giáng Sinh.

9. Giáng Sinh trong chiến tranh

Tinhte-Giang-sinh-chien-trah.

5 tháng từ khi chiến tranh thế giới thứ 1 nổ ra, binh lính dọc theo mặt trận phía Tây đã có một đêm mừng Giáng Sinh. Khi đó, dù đang chiến đấu ở 2 chiến tuyến khác nhau, nhưng cả 2 phe vẫn cùng nhau hát các bài hát Giáng Sinh. Sáng sớm hôm sau, những binh sĩ người Đức đã leo lên từ các chiến hào và bắt đầu hướng về phía quân đồng đồng minh để đồng thanh nói lời “Merry Chrirstmass” bằng tiếng Anh. May mắn thay, đó hoàn toàn là những hành động thật lòng và những chiến sĩ người Anh cũng đáp lại bằng cách tiến ra bên ngoài, chào đón và bắt tay với người Đức. Thậm chí, họ còn dùng thuốc lá để làm quà trao cho nhau và cùng chơi đá bóng. Tiếp theo hành động đẹp đó là thỏa thuận ngừng bắn Giáng Sinh năm 1914, một nghĩa cử cao đẹp trong chiến tranh.

10. Giáng Sinh trên khắp thế giới

Tinhte_Giang-Sinh-201404.

Dựa trên nguyên bản ban đầu, ngày Giáng Sinh sẽ được biến tấu theo những cách khác nhau tùy thuộc vào nền văn hóa mà nó du nhập. Tại Phần Lan, người ta thường đi tắm hơi vào đêm Giáng Sinh. Trong khi đó, người Bồ Đào Nha lại tổ chức một bữa tiệc trong đêm Giáng Sinh nhằm cầu cho cuộc sống hiện tại và những linh hồn đã qua đời. Tại Hy Lạp, một số người tin rằng những con yêu tinh kallikantzeri sẽ chạy trong suốt 12 ngày Giáng Sinh và do đó, mọi người sẽ không tặng quà cho nhau cho đến ngày 1/1.

Nhờ vào vị trí địa lý đặc biệt nên phần lớn người Úc và New Zealand thường thưởng thức thời gian Giáng Sinh trên bãi biễn với các bữa tiệc nướng. Tỏng khi đó, tại Tây Ban Nha, người ta sẽ tổ chức sự kiện xổ số lớn nhất thế giới trong ngày lễ này.

Trên đây là 10 thông tin thú vị xoay quanh ngày lễ Giáng Sinh. Giây phút đêm Noel đã cận kề, những bài hát Noel dường như ngày càng vang lên nhiều hơn và không khí cũng nóng lên theo từng phút. Cám ơn các bạn đã dành thời gian theo dõi bài viết. Hy vọng rằng bài viết cung cấp thêm một số thông tin thú vị xoay quanh ngày lễ lớn trong mùa đông này để các bạn có dịp kể cho nhau nghe khi vui chơi Giáng Sinh. Cuối cùng, chúc các bạn có Giáng Sinh vui vẻ và hạnh phúc. Bạn nào có hình ảnh đẹp Giáng Sinh xung quanh thì cũng có thể chia sẻ thêm bên dưới cho mọi người cùng vui nhé. :D

Tham khảo Time, GotQuestion, Thfw, LV, PlayBuzz

[Discovery] Bộ nhớ điện trở RRAM – ứng cử viên sáng giá thay thế cho NAND Flash trong tương lai

RRAM_Design.
Thiết kế bộ nhớ RRAM của Crossbar.

Sau khi giới thiệu công nghệ bộ nhớ điện trở (RRAM hay ReRAM) hồi tháng 8 năm ngoái thì năm nay, công ty công nghệ bộ nhớ Crossbar đã vừa công bố chuyển sang giai đoạn thương mại hóa thiết kế. Điều này cũng chứng minh rằng công ty có thể chế tạo phần cứng với các máy móc sẵn có, qua đó có thể tìm kiếm các nhà sản xuất để đưa bộ nhớ RAM điện trở đến với thị trường.

Công nghệ bộ nhớ RRAM lưu trữ dữ liệu bằng cách tạo ra điện trở trong một mạch dẫn thay vì trực tiếp giữ điện tích. Khi một dòng điện được áp đặt vào một vật liệu, dòng điện sẽ làm thay đổi điện trở của vật liệu. Trạng thái điện trở sau đó có thể đo đạt và kết quả sẽ được mã hóa 1 hoặc 0.

So với bộ nhớ NAND flash, RRAM có nhiều ưu điểm thuộc về bản chất. Bộ nhớ NAND có tuổi thọ giới hạn và giảm dần khi cell nhớ trở nên nhỏ hơn, các điểm (node) xử lý chu trình ghi/xóa cũng bị thu hẹp lại và số lần sửa lỗi yêu cầu ở mỗi node mới cũng tăng dần qua thời gian. NAND có tốc độ truy xuất cao nhưng việc đọc/ghi dữ liệu cũng làm giảm tuổi thọ bộ nhớ. Cho nên các nhà sản xuất bộ nhớ hiện nay đều tập trung cải tiến các vi điều khiển bộ nhớ NAND hoặc giao tiếp hệ thống thay vì hiệu năng cơ bản của NAND.

Crossbar_RRAM.
Đối chiếu kích thước giữa 1 bộ nhớ NAND 8 GB và 1 bộ nhớ RRAM 8 GB, cả 2 đều dùng quy trình 25 nm.

RRAM có thể giải quyết rất nhiều trong số những vấn đề vừa nêu. Không giống như NAND, RRAM không cần được xóa trước khi được ghi và có tốc độ truy xuất nhanh hơn NAND rất nhiều lần. RRAM cũng tiêu thụ ít năng lượng hơn và theo Crossbar thì nếu như NAND cần đến 1360 pJ (picoJoule)/mỗi cell để hoạt động thì RRAM chỉ cần 64 pJ/cell. Thêm vào đó, Crossbar cho biết công nghệ này hỗ trợ lưu trữ 2 bit dữ liệu/cell (tương đương với bộ nhớ MLC NAND) và có thể được chế tạo thành các lớp 3D chồng lên nhau. Ngoài ra, công ty cũng cho rằng công nghệ có thể được sử dụng để làm giảm độ phức tạp của các vi điều khiển – một lợi thế tiềm năng đáng chú ý khi độ phức tạp và chi phí sản xuất bộ nhớ đang ngày một tăng.

RRAM_App.

Tuy nhiên, việc thương mại hóa RRAM dưới dạng phần cứng tiêu dùng vẫn cần thêm thời gian. Trước mắt, công ty đã cấp phép cho các nhà phát triển chip SoC, mạch tích hợp dành cho ứng dụng đặc thù ASIC và mạch lập trình tùy biến FPGA với các sản phẩm mẫu dự kiến sẽ được chuyển giao vào năm 2015. Những ứng dụng đầu tiên được hướng đến sẽ là các hệ thống nhúng và bộ nhớ cấp thấp do nhu cầu dung lượng bộ nhớ không lớn và hoạt động càng tiết kiệm năng lượng càng tốt.

Mặc dù vây, có một điều vẫn chưa thể thay đổi đó là lộ trình dài hạn để thay thế bộ nhớ NAND. Samsung, Intel, Micron là những công ty đã đầu tư hàng chục tỉ đô để sản xuất bộ nhớ NAND và họ dĩ nhiên không có ý định chuyển sang một chuẩn mới ngay lập tức. Các công ty trong ngành công nghiệp luôn tự hào về việc nhanh chóng đón nhận các công nghệ mới nhất, tuyệt vời nhất nhưng sự thật lại rất khác biệt. Hầu hết các sản phẩm thành công trong ngành công nghiệp máy tính đều là những sản phẩm mở rộng, cải tiến từ những thành quả trước đó về khía cạnh hiệu quả chi phí. Việc một sản phẩm mới hoàn toàn vượt lên và định hướng thị trường hiếm khi xảy ra.

Hiện tại, bộ nhớ NAND 3D hay Samsung gọi là V-NAND sẽ dẫn dắt thị trường trong ít nhất là 3 năm tới, từ 2015 đến 2018. Tuy nhiên, điều này không có nghĩ RRAM sẽ không có mặt trong các ứng dụng thương mại và doanh nghiệp. Thực tế cho thấy thị trường đã dễ dàng đón nhận các giải pháp bộ nhớ NAND đắt đỏ để khai thác các chuẩn như PCI Express hay NVMe khi các sản phẩm này có thể mang lại thời gian phản hồi nhanh hơn nhằm đáp ứng cho các ứng dụng yêu cầu về độ trễ thấp. Do đó, RRAM có tiềm năng mang lại thời gian phản hồi tốt hơn và đủ khả năng đáp ứng cho một số lĩnh vực nhất định.

Trước mắt, bộ nhớ NAND 3D sẽ là xu hướng tiếp theo cho ngành công nghiệp bộ nhớ bởi nó cho phép các công ty chuyển sang quy trình sản xuất nhỏ hơn với mật độ node cao hơn. Samsung hiện tại đang phát triển V-NAND trên công nghệ xử lý 40 nm. Tuy nhiên, NAND 3D vẫn là NAND và nó vẫn tồn tại những hạn chế về mặt chức năng dài hạn. Vì vậy, chúng ta cần phải thay thế bộ nhớ flash với những dạng bộ nhớ bền hơn nếu muốn tiếp tục cải thiện mức tiêu thụ năng lượng và hiệu năng xử lý trên tỉ lệ bộ nhớ. RRAM có vẻ như là một tùy chọn có khả năng hiện thực hóa nhất.

Theo: ExtremeTech

[Dev Tip] Understanding Windows Identity Foundation (WIF) 4.5

First things First

If you are looking for an article that shows a lot of code and dissects the new WIF 4.5 APIs, then you won’t find what you need here.

My aim in this article is to explain the “why” and the “what” rather than the “how”. Once you understand that, the “how” becomes really simple. This article does not assume pre-knowledge of the topics of federation, claims, and WIF so it’s suited for beginners. However, I think that mid-level knowledge audience will also benefit from it. If you’re like super-expert, well please contact me to help me in my current project.

What Exactly is the Problem?

Authentication (and authorization) is an ever present challenge for most applications. The challenge that these applications face is the same: authentication logic creeps into the application code and becomes coupled with it; any change to the authentication requirements will result in a change in the application itself.

Say for example that your user store is SQL Server and new business mandates adding an existing Oracle-based user store to your list of users, or maybe you want to mix your authentication to support both custom user stores (SQL Server or Oracle) with Active Directory user store. And what about social media? It’s increasingly popular nowadays for applications to allow authentication via services such as Google and Facebook.

Here is another tough case: assume you used to ask you users for username/password combination to log in. Now based on certain needs, you want them also to supply additional information such as a one-time code. This will certainly lead to UI change for your login page as well as code change.

In all these cases, something has to change in your code. Of course, having a good architecture with a proper separation of concerns will ease up the change. However, the idea is that you still have to manage this authentication logic instead of focusing on the business side of your application.

Claims-based authentication is the architecture that solves this problem.

Claims-based Authentication

Claims-Based architecture allows you to delegate authentication logic into another entity. This entity is a “some” layer which abstracts all authentication related coding and gives your application what it needs: is the user authenticated or not, and some information about the user (called claims or assertions) that lets your application take authorization decisions.

The claims-based architecture defines the following actors:

  • Subject: the entity that needs to be authentication. This can be a user that wants to log in to your application, or a piece of code in your application that wants to access a web service.
  • Relying Party (RP): the application (in case the Subject is a user) or the web service (in case the Subject is application code) that needs to delegate the authentication logic
  • Identity Provider (IP): the entity (that “some” layer mentioned before) that actually holds the authentication logic. The IP talks to the user stores as appropriate and performs actual authentication.
  • Claim: When an IP performs successful authentication, it returns to the RP a set of claims. Claims are statements about the authenticated entity – for example birth date, department, role, etc… – that gives the RP information to take authorization decisions.
  • Token: Claims travel inside a token. Although a token can be a username/password combination or even a simple string such as bearer token in OAuth 2.0; in this context tokens can be either XML-based such as SAML tokens or binary-based such as X.509 certificates.

In addition to the above definitions, WS-Federation and WS-Trust protocols define another term called Secure Token Service (STS). STS is the web service exposed by the IP that provides the authentication service.

Before the claims-based flow can start, the RP and IP need to publish their policies. In abstract terms, a policy is a contract published by an entity that specifies the terms and conditions that other entities must obey before establishing communication.

In this context, the policy published by the IP specifies the supported protocol(s) and security requirements as well as supported claim types. Similarly, the policy published by the RP specifies its own protocol, security, and claims requirements as well as the list of IPs it trusts to delegate authentication to.

The rest of the article discusses WS-Federation (and related WS-standards) and its implementation in WIF, while I will also briefly discuss SAML 2.0.

The WS-* Mania

For some, the WS-* standards are something to avoid. They tend to strike developers as being overly complex. Indeed complex they are. However, with the advent and continuous enhancement of developer libraries, most of the times working with WS-* standards is nothing more than configuration tweaking. Granted however, you always need to understand what is going behind the scenes if you really want to understand the architecture.

This section discusses – briefly – some core WS-* standards that are related to WS-Federation.

WS-Security

WS-Security is a SOAP extension that adds authentication/authorization, message protection, and message integrity to SOAP messages.

  • Authentication/authorization: authentication is implemented using security tokens while claims carried inside a security token aid in authorization. Although can be extended, the three types of tokens you’d usually see are Username, Binary, and XML-based tokens.
    • Username tokens: these are the plain-old username/password combinations sent in the SOAP header. Verification of identity can be achieved by hashing the password or applying a digital signature.
    • Binary tokens: these usually come in two flavors: X.509 certificates and Kerberos tickets.
      • X.509 certificates: an X.509 certificate is the public key container of a public/private key pair. Obviously since it contains a public key it cannot be relied upon for authentication by itself. The certificate is signed with the private key portion of the sender. The receiver uses the public key to verify the signature. Since the private key is unique for the sender, signature verification proves identity
      • Kerberos tickets: if a Kerberos infrastructure is already in place, WS-Security recognizes Kerberos tickets as a valid security token type
    • XML-based tokens: XML tokens were published as an ad-on specification to WS-Security. XML tokens contain a set of claims about the sender. Similar to X.509 certificate tokens, XML tokens must be accompanied by a signature generated by the sender so that the receiver can verify its identity. Probably the most dominant form of XML tokens is SAML token.
  • Message protection: Whereas at transport level message protection is established using SSL, at message level this is done via XML Signatures. Depending on the configuration, WS-Security uses either a symmetric shared key or an asymmetric public/private key pair to encrypt the required message content. In the symmetric approach the shared key must be exchanged securely prior to communication. In the asymmetric approach the sender encrypts the (required) message content using the receiver’s public key and the receiver decrypts it using its private key. Most of the time though, the approach used is a combination of both due to the fact of asymmetric approach being compute-expensive. In this hybrid approach, asymmetric encryption is used to exchange a shared key and then this shared key is used for encryption for the rest of the session communication.
  • Message Integrity: as discussed in the authentication section, XML signatures are used to establish user identity. It is also used to establish message integrity; i.e. that the message has not been tampered with. By attaching a signature with a message, the receiver recalculates the signature and verifies integrity if both signatures match. Similar to encryption, a hybrid approach is usually used to reduce the cost of asymmetric-based signatures.

WS-Policy

WSDL does a good job describing basic web service requirements such as message schemas and authentication headers. However, WSDL cannot describe contractual requirements such as security. For example, recall form the previous section of Claims-based architecture, that an RP-IP interaction is governed by a set of security policies. These policies cannot be described using WSDL; instead they are described by WS-Policy and its related specification WS-SecurityPolicy.

In general, there are WS-Policy assertions for security, reliable messaging, sessions, transactions, reliable messaging, among others. In WCF, these policies are specified either as code attributes or configuration sections.

  • WS-Policy: a specification that defines a framework for describing policy assertions. An assertion is a requirement or preference of the service. This specification defines a common language regardless of the assertion domain (security, transactions, reliable messaging, etc…).
  • WS-PolicyAssertion: a specification that defines general messaging-related assertions for use with WS-Policy. Separate assertions exist for different domains; for example, WS-SecurityPolicy, WS-AtomicTransactions, and WS-ReliableMessaging.
  • WS-PolicyAttachment: a specification that describes how policies are attached to WSDL (and UDDI).

WS-Addressing

WS-Addressing specification provides elements that enable end-to-end transport-independent message transmission. For example this allows you to implement message routing (previously WS-Routing) where – based on some message criteria – you can explicitly specify the next hop in the message route. Also some of the other things that you can do is specify a different response or fault return URLs to a message and thus sending the response to a different endpoint than the originator.

WS-Trust

As discussed in the claims-based architecture, you can delegate your application authentication logic to another entity which issues claims that your application. The part I skipped is how to make your application “trust” these claims? What prevents a fake IP from generating a claim and sending it to your application which then will grant him access?

Let’s take this one step further: assume two companies A and B want to conduct business. Company A want company B users to access its application. How can this be done? One way is for A to provision B users; however, this clearly is a troublesome solution as A will have to manage and control B users. Wouldn’t it be a much better solution if we make A “trust” B users without actually managing them?

WS-Trust is a specification that tackles the above two scenarios. WS-Trust introduces the concept of a Secure Token Service (STS), which is a web service that is responsible of generating claims that are trusted by consumers. In the first scenario (authentication delegation), you have your application establishing a WS-Trust relationship with an STS service for an IP. In this second scenario (companies A & B), both parties establish a WS-Trust where A trusts an STS for B IP; this way B users can carry tokens issued by their IP-STS and present these tokens to A, which trusts the STS and thus grants access.

WS-Trust defines a message request called RequestSecurityToken (RST) issued to the STS. STS in turn replies via a response called RequestSecurityTokenResponse (RSTR) that holds the security token to be used to grant access. WS-Trust describes the protocol for requesting tokens via RST and issuing tokens via RSTR.

WS-SecureConversation

WS-SecureConversation specification provide a mechanism to improve a service response time when the client engages with a lengthy communication with that service.

When a client sends a message to a secure service, part of the request will be dedicated to credential negotiation and authentication. At transport level, this is accomplished in SSL handshake process so any consequent requests use the secure session already established. WS-SecureConversation achieves the same on the message level.

WS-SecureConversation specification states that the client first sends an RST (from the WS-Trust specification) to the service. The service validates the credentials within the RST and issues back a token called Secure Context Token (SCT) with a symmetric key to perform the cryptographic operations for the remaining communication.

These tokens are used by WS-Security for authentication and integrity and are described at both ends (IP & RP) using the WS-SecurityPolicy assertion.

WS-Federation

So we’re finally at the WS-Federation section! All the previous specifications discussed lead to this place.

Let’s start by defining federation: Federation refers to multiple security domains (also called realms) – typically multiple organizations in B2B scenarios – establishing trust for granting access to resources. Carrying on with the terminology we have been using, an RP in domain A can trust an STS IP in domain B so that B users can access resources of A.

WS-Federation build on WS-Trust and simplifies the creation of such federated scenarios by defining a common infrastructure for achieving federated identity for both web services (called active clients) and web browsers (called passive clients).

WS-Federation says that organizations participating in federation should publish communication and security requirements in Federation Metadata. This metadata adds federation specific communication requirements on top of the WS-Policy (and WS-SecurityPolicy) metadata described before. For example, token types and single sign out requirements are examples of what is defined in the Federation Metadata.

WS-Federation does not mandate a specific token format, although as we will see later, SAML tokens are used heavily.

Identity and Access Control in .NET 4.5

Identity and Principal pre-.NET 4.5

If you have been creating applications in .NET framework since v 1.0, chances are you have already came across interfaces IIdentity and IPrincipal. IIdentity would represent the identity of the authenticated user while IPrincipal contains that specific identity in addition to a method to check if the user is a member of a certain role.

Different implementations existed for IIdentity and IPrincipal:

  • WindowsIdentity and WindowsPrincipal are used for windows, active directory, or Kerberos authentication
  • GenericIdentity and GenericPrincipal are used for custom authentication such as forms authentication

As you can see, role-based access (or authorization) up until .NET 4.0 was really restricted to the IsInRolemethod of the IPrincipal and its implementations. There are multiple ways to call this method; you can call it directly via the API, or you can use attribute-based authorization (PrincipalPermission), or you can use the authorization element in the web.config. Regardless of the method, your role-based access power was limited to checking if the logged in user belong to a certain group or not.

Now if you have reached so far in this post, you will for sure have noticed that claims-based authorization gives you much bigger power. Using claims you can make access decisions based on things like a user birth date, national id, and of course roles, among others. The idea is that the system that performed authentication (the IP in our literature) attaches any attributes agreed with the RP as a set of claims (assertions); the RP then uses these claims to make suitable authorization decisions.

So are claims not supported pre-.NET 4.5? Yes they are, and here’s how:

WCF 3.0 Claim Transformation

Before Windows Identity Foundation (WIF) 1.0 was shipped, Microsoft’s first attempt to incorporate claims into their security model came under the umbrella of WCF. In WCF 3.0 Microsoft included the System.IdentityModel assembly which basically generated a set of claims for every security token authenticated by WCF. WCF 3.0 shipped with the following classes:

  • System.IdentityModel.Claims.DefaultClaimSet, which represents any additional generic claims sent to the service
  • System.IdentityModel.Claims.X509CertificateClaimSet for converting X509 tokens to claims
  • System.IdentityModel.Claims.WindowsClaimSet for converting Windows tokens to claims

WCF 3.0 included authorization policies to perform the actual claim transformation.

The problem in this approach was that now .NET developers have two completely different security infrastructures for web applications (IIdentity and IPrincipal) and for WCF services (System.IdentityModel). So if you have an application which consists of both web app and web service, then you’ll have to write nearly the same code twice against two different libraries.

WIF 1.0

Microsoft enhanced their claim infrastructure in In WIF 1.0. Instead of the System.IdentityModel used in WCF 3.0, they shipped a new assembly of name Microsoft.IdentityModel.

The need to support claims was achieved by adding another implementation of IPrincipal, calledIClaimsPrincipal which will be populated once claims-based authentication is used. As you can see, this way WIF combined both worlds: that of base classes IIdentity and IPrincipal and that of WCF 3.0 claims infrastructure.

Here is how you would retrieve claims for a claims-authentication enabled application:

IClaimsIdentity identity = Thread.CurrentPrincipal.Identity as IClaimsIdentity;
string email = (from c in identity.Claims where
   c.ClaimType == System.IdentityModel.Claims.ClaimTypes.Email
   select
   c.Value).Single();

As you can see, we’re casting the current principal’s identity to get the IClaimsIdentity.

Now even with this improved approach, can you already spot the drawback? Well the issue here is that with this approach if you use WindowsPrincipal or GenericPrincipal you won’t get claims as IClaimsPrincipal is just another implementation of IPrincipal much like the other two. It’s either this or that. This makes claims support in .NET 4.0 not a first class citizen.

Identity and Principal in .NET 4.5

In .NET 4.5 claims are made available regardless of the authentication type. What Microsoft did was creating a new implementation of the base IPrincipal, called ClaimsPrincipal. Then they made every other principal (WindowsPirincipal and GenericPrincipal) derive from ClaimsPrincipal, and they removed theIClaimsPrincipal of .NET 4.0. This way, you will get claims all the way; for example even if you use forms authentication, all the attributes you pull from a membership provider will be carried in claims.

This way, role based access is unified for all authentication types and more important, it’s much richer than the simple IsInRole approach because you now depend on claims to take decisions.

Let’s see how you can retrieve claims for a claims-authentication enabled application and compare this to the same code you had to write pre-.NET 4.5:

string email = ClaimsPrincipal.Current.FindFirst(ClaimTypes.Email).Value;

ClaimsPrincipal.Current basically plays the same role that Thread.CurrentPrincipal used to play.

Let’s see the new claims-based model in .NET 4.5. Below you can see the debugger of a VS 2012 web application using WindowsIdentity:

You will notice that the base class is of type System.Security.Claims.ClaimIdentity which as explained is the new base class for the identity classes as of .NET 4.5. Also notice how although we used windows identity, claims are populated with windows login specific information. In .NET 4.5, you will get claims no matter what.

The below figure shows a similar result when we define a GenericIdentity (simulating a forms authentication for example). Again the base class is common and a claim of type name is generated by default:

When using forms authentication, you will get the Name claim by default. You can get additional claims by using the ASP.NET Role Manager.

Let’s briefly discuss some more concepts and capabilities of .NET 4.5 claims model.

Supported Credential Types

As discussed before, the biggest advantage of the claim model is that regardless of the authentication mechanism used, your application will always rely on claims to achieve authorization. So your application logic does not really care about the actual type of the security token that was used for authentication; authentication logic is a separate concern with its separate module, your application gets claims and you use these claims to take authorization decisions.

Now this authentication layer I am talking about, can be part of your application itself living in a separate module, or – as discussed in the very beginning – can be a separate STS that your application trusts in the IP/RP model. In this discussion our focus is on .NET 4.5 so authentication will be part of the application, the next section dives into WIF 4.5 where you will see STS in action.

So, you .NET 4.5 application can use any of the following security tokens:

  • Windows/AD/Kerberos
  • Forms authentication
  • Client certificates
  • SAML tokens
  • Other extended token types

Once the authentication layer is passed, your application will get claims in the ClaimsPrincipal shown before.

Claims Transformation

Before the claims actually hit your application, it can be subjected to a transformation/validation layer. Once example of transformation need is that you know claims will come is a certain format and you would like to change this format to suit your application coding. An example of validation is – say your application accepts claims from an STS – and you want to make sure before handing the claim to your code that the minimum set of required claims are actually present.

To implement this transformation/validation, you will have to override a class calledClaimsAuthenticationManager.

Authentication Sessions

The logic you wrote in the ClaimsAuthenticationManager derived class can be run at each and every request, or you have the option to cache its outcome if you believe its logic is expensive. The cached value can be saved in cookies for ASP.NET applications and using WS-SecureCoversation for WCF services.

Claims-based Authorization

Finally we are the stage of actually performing authorization decisions based on the claims. The classClaimsAuthorizationManager is what you’d want to derive from to implement your authorization logic. This class contains the method CheckAccess which can be called whenever you want to make an authorization decision.

This way you won’t mingle authorization logic directly into your business logic (which typically was the approach used in the days of the IsInRole checking).

Once again, I want to remind you that this approach of using claims inside your application is the same regardless if whether the claims are generated by authentication logic as part of your application or if the claims are given to your application by an STS that it trusts. In both cases, you have the ability of using theClaimsAuthorizationManager to minimize the coupling between your business logic and the authorization decision.

One final note: the claims-based model is the same for web applications and WCF services. So the .NET 4.5 code to retrieve, transform, and authorize claims works the same regardless of whether the consumer is a .NET 4.5 web app or WCF service.

Windows Identity Foundation (WIF) in .NET 4.5

In the previous section I discussed the claims model in .NET 4.0 vs. .NET 4.5 and showed you how claims are now first class citizens in .NET 4.5. However, the previous section still used the “traditional” authentication mechanism where authentication is still your application’s responsibility. Be cautious though, I do not want the previous section to deviate your attention from the main focus of this article: delegating authentication responsibility to an external entity.

WIF is Microsoft’s technology for encapsulating the inner workings of WS-Federation (and WS-Trust) behind a .NET library which makes it easy for developers to create claims-based apps without the need to know the details of the specs we discussed previously.

As was discussed in the previous section, we have seen how identity and access support in .NET passed through multiple stages, from the simple IsInRole checking, to claims support in WCF 3.0, to WIF 1.0 and then to .NET 4.5.

WIF 4.5 is where this ends (and the new work begins!). In .WIF 4.5, Microsoft did yet another naming change to the assemblies:

WIF in Action

VS 2012 provides you with the tools to quickly set up your RP and use a local STS. Creating an STS should be really the last thing that you would try to do. However, you will only use this STS for development/testing purposes. Running an STS is not a simple task as its business critical and relies on complicated protocols and cryptographic operations.

STS commercial products are available and you are likely to use them. Some of these products are:

  • Active Directory Federation Services (ADFS) v2
  • IBM Tivoli Federation Manager
  • Oracle Identity Manager

ADFS v2 is the topic of the next article.

So why does Visual Studio give you this local STS? Simply to aid you during the development (and possibly testing) phase where the STS product might not be accessible to you. Since your RP does not hold the authentication logic anymore, all what you have to do before going to live is to edit the policy for your RP to trust the new STS instead of the one created using visual studio.

Let’s roll.

Create a new VS 2012 ASP.NET 4.5 web forms application. Right click the project and select “Identity and Access”. This will display a wizard giving you three options: ADFS2 and ACS will be discussed in future posts, I will just quickly note that ADFS2 is the STS of AD and ACS is the STS on Azure.

Select the option to create a local STS. In the Local Development STS tab, you can select the SAML token version to use, the local port of the STS, but most important you can select the claims that the STS will give your RP. In WIF 1.0, you had to manually edit the local STS code to change the set of claims; this way is much cleaner and true to the promise of isolating you (the RP owner) from the authentication logic. Notice that you can use from the many pre-defined claim namespaces and you can define your own. Accept the defaults to close the wizard.

VS 2012 has now equipped your RP to trust a local STS and set up the policy between them. To see this, let’s examine the web.config of the RP:

  • Forms Authentication removed: your RP now is neither windows nor forms authentication-base. It is a claims-based application, so forms is disabled because forms is the default when creating a VS web forms app.
  • Two HTTP modules that makes WIF magic possible:
    • WSFederationAuthenticationModule: this module intercepts incoming requests and redirect unauthenticated ones to the trusted IP(s). For authenticated requests it processes claims within the security token and presents them to your application in a consumable format.
    • SessionAuthenticationModule: this module takes care of session management after an authentication is established. The WSFederationAuthenticationModule module is bypassed andSessionAuthenticationModule handles requests until the session is expired or a sign-out flow is invoked.
  • audienceUris: lists the URIs that your RP will consider valid for the received tokens
  • trustedIssuers: the list of trusted IP certificates that the RP will accept signatures from to verify the token
  • wsFederation: configures the WS-Federation protocol, such as using the passive protocol flow, the IP that the protocol will talk to, and the realm which is basically the ultimate return-URL that the protocol flow will end up in – the RP itself in this case.

In addition, VS 2012 has created a FederationMetadata.xml file in the RP solution. Recall from the discussion of WS-Federation that organizations participating in federation should publish communication and security requirements in Federation Metadata. This XML file holds these requirements for this RP.

Now run the application, quickly notice the browser navigation and you will see that your application gets redirected to the local STS which performed the (hardcoded) authentication and returned back to your application as an authentication user (assume you’re Terry for a moment!). You can now access the claims inside your application just like we have seen before.

Now let’s see what happened in the background to examine WS-Federation and the supporting protocols discussed before in action. To do so, I will use Fiddler:

Step 1: A user browses the RP

You asked for the application via the browser. The WIF HTTP module WSFederationAuthenticationModuledetects that you are not authenticated, so it redirects the browser back with a 302 response and with a Location header that contains the address of the IP-STS at which you must authenticate. In addition, a set of WS-Federation protocol query strings are also supplied to govern how the flow will behave:

  • wa: with a value of wsignin1.0 which means that this is a sign in request (note that WS-Federation also supports sign out flow, so this parameter is mandatory)
  • wtrealm: this is the RP itself, and it represents the intended consumer of the token
  • wct: this is an optional parameter that specified the time of the response of the RP. This might be used as indication to possible attacks if the IP sees that there is a time lag between this parameter value and the actual time it received the sign in request

Step 2: The browser sends a GET request to the STS

The browser then uses the STS address in the Location header and the query strings discussed before to assemble a sign in request to the STS. Here is the request made to the local STS:

Step 3: The IP-STS performs authentication

In “real” scenario, the STS will normally present you with an authentication form that you would supply your credentials to. This procedure of STS authenticating users – as mentioned before – is outside the scope of WS-Federation and thus WIF. The STS can authenticate you against an AD, a custom user store, or even using an X.509 certificate. This depends on the type of the RP application and where the users are coming from. Regardless of the mechanism to authenticate, the STS will – assuming successful authentication – generate a security token containing the claims agreed between the IP and RP via policy.

Step 4: The STS sends the response back to the browser

The STS sends back to the browser a hidden form with will POST back to the RP. The form contains the following information:

  • wa: same as before indicating a sign-in flow
  • wresult: contains the SAML security token issued by the STS.

If you carefully examine the response, you will see many of the protocols discussed before coming into play:

  • The RequestSecurityTokenResponse (RSTR) of WS-Trust carries the token collection
  • XML Signature of WS-Security is used to provide message integrity and trust between the IP and RP
  • WS-Policy – driven by the Federation Metadata – indicates rules such as token lifetime
  • WS-Addressing is used to identify the endpoint reference for the passive request (i.e. the RP)

I reformatted the content for ease of display, here you can see these protocols in action:

Note: There is a difference between SAML-P (the protocol) and SAML token. SAML-P is a full blown protocol much like WS-Federation. SAML token is a token type that can be used independent of SAML-P, and it’s one of the token types frequently used in WS-Federation.

I will briefly touch on SAML-P 2.0 at the end of this article. 

Step 5: The browser posts back to the RP

The browser uses the hidden post form from the previous step to post the result shown in the previous step back to the RP

Step 6: The RP verifies the token

Verifying a token involves multiple checks that could take place based on each situation and policy. Some of these checks are:

  • Integrity: in case digital signature is used, the RP uses the IP public certificate included in the request to verify that the digital signature is valid
  • Expiration: in case an expiration for the token is present, the RP verifies that the token is not expired
  • Decryption: in case encryption is used, the RP uses its private key to decrypt the contents. In the above example, encryption was not used as we were in the passive (web browser) case, later I will discuss the active case and illustrate the difference.
  • Source: using the policy, the RP makes sure the token is issued by a trusted IP
  • Claims: also using the policy, the RP checks that the set of claims issued are the ones agreed on

Step 7: A session cookie is issued

Once the token is verified, the RP issues a session cookie back to the browser so that next requests do not pass through the same WS-Federation process.

WIF for Active Clients

The browser-based scenario we have just seen is called a passive scenario. Passive clients are those that do not possess the WS-* capabilities. Browsers are passive because they just perform redirects they are told to, but by themselves browsers have no notion of WS-Federation.

Another type of clients are active ones. Active clients are those that can perform WS-* operations; an obvious example are WCF services. A WCF service can also act as a claims-based enabled RP. In this scenario, the client (the Subject as per the defined terminology) is an application calling the WCF service which requires claims-based authentication from a trusted STS.

The full cycle goes as follows:

  • An application reaches a line where it is invoking a WCF service. The WCF service itself is an RP configured for claims-based authentication.
  • The WCF client library at the application finds out that the WCF service needs a security token to grant access. The library then issues an RST to the STS.
  • The STS replies back with a security token via RSTR
  • The client application then uses this token to access the WCF service. Now here you can spot a major difference between the passive and active scenarios. Recall in the passive case that the client (browser) had only Https as option for encrypting its request to the RP – called transport level. In the active case, the client (application) can actually use the token to perform custom message level encryption on the message. Message level security has the benefits of better performance as we can be selective for which parts of the message are deemed sensitive and thus to be encrypted and it also supports end-to-end messaging.

The good news is that when it comes to WIF, you do not have to learn anything new than what you saw in the passive case. The same programming model applies. Again you can right click a WCF project in VS 2012 and configure it as an RP using the “Identity and Access” wizard. The defining difference between active and passive clients becomes clear when you inspect the web.config of the WCF service; you will see the ws2007FederationHttpBinding in use, which again shows you that active clients are WS-* aware.

Federation Providers

So far the discussion has been centered on one role that STS can play, and that is issuing claims on behalf of an IP; and thus it has been called an IP-STS. However, an STS can play another roles; the role of a Federation Provider.

Let’s recall the scenario I discussed before of the two companies A and B wishing to enter a federated business agreement. In that scenario I gave an example of B users needing to access a (single) application in A and how that application is configured as an RP for an STS in B.

Now let’s extend the scenario a bit: instead of B users wanting to access a single application in A, both companies want to extend their partnership and now B users must be able to access multiple A applications. Under the role of IP-STS we have discussed so far, every A application must establish trust with B IP which in turn must provision every A application.

A far better solution is for A to expose a Federation Provider. A Federation Provider is a Resource STS (R-STS) that sits on the resource side (on the relying party side – A domain in this case). Company A applications then establish trust with the R-STS and B then provisions this STS only.

A typical flow will then goes as follows:

  • An employee on B domain tries to access an A application
  • A detects (via WIF for example) that the user is not authenticated and redirects the request to the STS it trusts; in this case it’s the R-STS on A’s domain
  • In its turn, the R-STS is configured to accept tokens from B IP, so the request is redirected back to B IP
  • The user authenticated herself again B IP using any mechanism defined by B
  • A request is submitted to the R-STS on A containing the token
  • R-STS processes the request and typically does one of 3 things:
    • Issue claims exactly as they were sent from B IP. Here the R-STS decides that the included claims satisfy A application needs
    • Modify claims based on some rules, for example to satisfy special formatting needs for A applications
    • Add new claims that the R-STS knows are important for A applications yet B IP had no information about. For example R-STS might maintain some information from previous transactions for a specific user.
  • The resulted token is then sent to the originally request A application which grants access

Once again, using WIF you can create your own local R-STS; although as explained before, in real scenarios you would go with commercial products. ADFS v2 is also suited to play the role of R-STS; for example its claims-transformation language is ideal for claims modification. Another great example is Azure Access Control Service (ACS) which also plays the role of a Federation Provider on the cloud.

Both ADFS v2 and ACS will be discussed in future articles.

SAML 2.0

I will close this article by briefly addressing SAML 2.0. Please note that I have never implemented this protocol myself, rather what I present here is a summary answer for the common question of WS-Federation vs. SAML just to get you going; but you’ll have a lot of reading to do if you want a definitive answer.

SAML 2.0 consists of two parts; a protocol (much like WS-Federation) that defines interactions and supported communication protocols, and a token format – conveniently called SAML token. The token specification is separate from that of the protocol, so you can use the token in another protocols. Actually that is what we have been doing in this article all along by using SAML tokens to carry claims in the WS-Federation protocol.

From a very high level point of view, SAML 2.0 protocol (SAML-P) achieves the same objectives of WS-Federation: it allows business partners to enter a federation agreement and allows delegation of authentication logic from an application (Service Provider) to an external entity (Identity Provider). The Identity Provider creates a SAML assertion that the Service Provider then validates to grant authentication. The SAML assertion is a SAML token containing claims.

SAML specification is actually divided into multiple parts:

  • SAML core: this specification defines the structure of the SAML assertions and the supported protocols. You can think of this as the base of every other specification
  • SAML bindings: each of the protocols described in the core specification is detailed in the binding specification where each binding has certain communication and formatting requirements
  • SAML profiles: the profiles specification puts together the different specification into a usage profile, such as the login and logout profile.
  • SAML metadata: this specification is basically what makes SAML-P tick. It defines the agreement requirements between the Service Provider and the Identity Provider to establish SAML-P (supported bindings, certificates, cryptography, etc…). Basically this is to SAML-P what WS-Trust is to WS-Federation.

WIF does not support SAML-P, although some time ago an extension to WIF that adds SAML 2.0 support was CTP’ed but has not took off since then. Here you can see the announcement:

http://blogs.msdn.com/b/card/archive/2011/05/16/announcing-the-wif-extension-for-saml-2-0-protocol-community-technology-preview.aspx

It’s not all bad however, ADFS 2.0 however fully supports SAML 2.0 protocol. Why is this great news? Well simply because of the range of interoperability scenarios that is now possible between two environments one adopting WS-Federation and the other SAML-P. So organizations that have already a SAML-P-based protocol infrastructure in place, does not need to change in order to be interoperable with an ADFS-based one.

[Discovery] Con người chịu lạnh được đến giới hạn nào?

2653954_Tinhte-nhiet-do-am.

Không khí lạnh đã lan tỏa tại khắp mọi nơi, không chỉ ở nước ta mà còn ở khắp mọi nơi trên thế giới. Hiện tại, Hà Nội đang là 16 độ C, California (Mỹ) đang 10 độ, Adadyr (Nga) thì nhiệt độ đã xuống tới âm 24 độ C. Một người bạn của mình tại Pháp cũng cho biết là nhiệt độ chỉ còn có 5 độ C và cô ấy bảo “đang lạnh sắp chết rồi!”. Câu nói của cô ấy làm mình tự hỏi con người chịu lạnh được tới bao nhiêu? Và ở mức nhiệt độ nào thì con người sẽ chịu không nổi nữa? Khi nhiệt độ hạ thấp thì cơ thể người sẽ chịu những tổn thương nào? Mời các bạn cùng mình tìm hiểu nhé.

Các cơ chế “tích hợp sẵn” trong cơ thể người để chống lại cái lạnh

Trên thực tế, cơ thể của chúng ta thật sự kỳ diệu, dường như tạo hóa đã chuẩn bị sẵn cho chúng ta các phương án để đối phó với sự khắc nghiệt của môi trường. Và đối với cái lạnh, cơ thể đã được “tích hợp” các cơ chế để bảo vệ tính mạng chúng ta.

Tinhte-co-gian-mach.

Ngay khi những cơn gió lạnh táp vào mặt, cơ thể chúng ta sẽ tự phản ứng bằng cách chuyển máu tránh xa da cũng như các bộ phận nhô ra bên ngoài như ngón tay, ngón chân và chuyển lượng máu đó vào khu vực trung tâm của các cơ quan này. Quá trình này được gọi là sự co mạch (vasoconstriction) và nó giúp giới hạn lượng nhiệt thất thoát ra ngoài môi trường.

Phản ứng thứ 2 từ cơ thể là run lên. Ngay khi nhiệt độ hạ xuống, một số người sẽ bắt đầu rùng mình, nổi da gà, răng đánh vào nhau và tiếp theo đó là rung bần bật lên. Thật ra, khi cảm nhận được cái lạnh, “cảm biến” sẽ gởi tín hiệu về não và não sẽ đáp ứng bằng một loạt những cảnh báo. Sự run rẩy là một trong những cảnh báo đó. Lúc này, cơ bắp của con người sẽ co giãn liên tục. Một cách nôm na, phản ứng này giúp cơ thể tạo thêm nhiệt độ, làm thân nhiệt tăng lên đồng thời cảnh báo cho con người biết rằng “đã đến lúc tìm nơi ấm áp hơn rồi đó.”

2 cơ chế trên được biểu hiện qua nhiều phản ứng khác, các bạn có thể theo dõi thêm tại bài viết “những phản ứng của con người khi gặp thời tiết lạnh.” Nhưng nếu các cảnh báo đã được não bộ đưa ra, nhưng chúng ta không thể tìm được nơi ấm áp để trú ẩn và cơ thể phải tiếp tục ở trong môi trường nhiệt độ thấp thì sao?

Tổn thương trước khi “đóng băng”

Tinhte-tuyet.

Dưới góc độ y học, khi nhiệt độ trung tâm (core temperature) của cơ thể hạ xuống thấp, cơ thể bắt đầu xuất hiện hạ thân nhiệt (hypothernmia). Hạ thân nhiệt từ trung bình đến nặng xảy ra khi thân nhiệt xuống dưới 32,2 độ C. Đây là một tình trạng lâm sàng của nhiệt độ dưới mức bình thường, lúc cơ thể không còn khả năng sinh nhiệt để duy trì các hoạt động bình thường. Và nếu cơ thể vừa chịu lạnh, lại bị ướt thì câu chuyện lại hoàn toàn khác. Cơ thể ẩm ướt sẽ mất nhiệt nhanh gấp 25 lần so với trong không khí.

Theo giáo sư John Castellani, trưởng khoa thân nhiệt và môi trường vùng núi tại Viện nghiên cứu môi trường quân y Hoa Kỳ cho biết nhiệt độ trung tâm bình thường của cơ thể người là 37 độ C và hiện tượng hạ thân nhiệt nhẹ sẽ xuất hiện lúc thân nhiệt xuống còn 35 độ C. Và nếu tiếp tục xuống nữa, tình hình sẽ tiến triển theo hướng xấu.

  • Thân nhiệt tại 32,2 độ C, cơ chế bù trừ bắt đầu suy giảm, trạng thái tâm thần có thể biến đổi và thậm chí, bạn có thể bị mất trí nhớ.
  • Thân nhiệt tại 27,7 độ C, bạn bắt đầu mất ý thức
  • Thân nhiệt xuống dưới 21 độ C, trạng thái hạ thân nhiệt nặng diễn ra và con người sẽ chết.

Kỷ lục ghi nhận thân nhiệt thấp nhất của một người trưởng thành từng được biết đến là 13,7 độ C. Lúc đó, người này đã bị ngâm trong nước lạnh và đóng băng trong thời gian khá lâu.

Các thương tổn nguy hiểm do nhiệt độ thấp

TInhte-ton-thuong-lanh.

Chưa đến mức phải chết, nhưng các tổn thương do lạnh giá gây ra cũng không kém phần nguy hiểm. Giáo sư John Castellani cho biết: “Nếu như nhiệt độ trung tâm của cơ thể phải mất khá lâu thì mới giảm xuống, thì nhiệt độ khu vực ngoại vi lại giảm xuống khá nhanh chóng.”

Các ngón tay, ngón chân sẽ dễ bị tổn thương do lạnh giá nhất do các khu vực này sẽ bị giảm lượng máu lưu thông trước tiên khi nhiệt độ hạ xuống. Thậm chí, mặc dù chúng ta có thể đeo găng tay hoặc mang tất nhưng nhiệt độ ngón tay, ngón chân vẫn sẽ rất thấp và nếu bạn lại bị đổ mồ hôi, sự ẩm ướt càng làm cho khu vực này bị mất nhiệt nhiều hơn.

Tuy nhiên, nhiệt độ không khí vẫn còn trên 0 độ C thì các tổn thương do lạnh giá vẫn chưa diễn ra. Theo các nhà nghiên cứu, những tổn thương thường xuất hiện khi nhiệt độ môi trường xuống dưới điểm đông 0 độ C. Castellani cho biết: Nếu bạn phải chịu những cơn gió lạnh âm 9,4 độ C trong thời gian dài thì sự tê cóng nặng sẽ xuất hiện và các thương tổn do lạnh giá mới tăng lên.”

Đồng thời, việc “quãng thời gian” để các tổn thương xuất hiện thì còn phụ thuộc vào các điều kiện môi trường. Ví dụ nếu nhiệt độ môi trường đang là âm 17,8 độ C và những cơn gió rét âm 28,3 độ C, bạn sẽ chịu các thương tổn do giá rét sau 30 phút đứng trong môi trường này. Tuy nhiên, thời gian này sẽ chỉ còn có 5 phút nếu bạn đứng trong môi trường âm 26 độ C và những cơn gió rét âm 48,3 độ C thôi liên tục.

Dù vậy, theo Castellani thì mặc dù những nguy cơ khá cao, nhưng con người có thể ra ngoài trong nhiệt độ môi trường cực kỳ lạnh và vẫn có thể sinh tồn. Bằng chứng là những người leo núi hoặc thám hiểu bắc cực,… Đồng thời, chúng ta đã có những người bơi qua eo biển Manche khi nhiệt độ nước rất thấp. Tuy nhiên, không phải khả năng chịu lạnh của mỗi người là như nhau, có thể những người này phải trải qua quá trình luyện tập trong thời gian dài để cơ thể dần thích ứng với nhiệt độ lạnh. Khi đó, cơ thể sẽ hình thành khả năng sản xuất và duy trì thân nhiệt hiệu quả hơn so với người bình thường.

Do đó, đừng nên mang cơ thể ra thí nghiệm khả năng chịu đựng nhiệt độ thấp. Bạn vẫn có thể mắc bệnh và chịu nhiều thương tổn do thời tiết lạnh giá gây ra nếu không được rèn luyện trước. Nếu vậy, hãy tự giữ ấm và nhắc nhở mọi người xung quanh cũng làm vậy để có được mùa đông tuyệt vời và nhiều sức khỏe nhé. Cám ơn các bạn đã theo dõi bài viết. Hy vọng rằng bài viết đã cung cấp cho các bạn thêm một số thông tin thú vị về mua đông của chúng ta. Có thể đọc đến những dòng này thì điện thoại hay tablet của các bạn cũng đã đủ nóng lên để sưởi ấm cho bàn tay các bạn rồi đó. Chúc các bạn có mùa đông ấm áp bên áo lạnh hoặc người thân nhé. Chúc vui vẻ.

Tham khảo BBC, LS

[Dev Tip] 5 Internal things that you should know about IIS Express

#1 : Where does the basic configuration information stored ?

The basic information related to the IIS Express are stored inside the project file (proj file)  within the property group information section.  To view it, Open the Project File in edit mode ( In this case I will strongly recomand you to use Visual Studio productivity Tool ) ; where you can edit the project file using “Power Command” as shown in the image below.

EditProjectFilesusingPowerCommands thumb 5 Internal things that you should know about IIS Express

Once you have the  project file in edited mode, you can search for below configuration section, where you can see the application information related to IIS Express are set.

IISExpressSettings thumb 5 Internal things that you should know about IIS Express

You can change the configuration editable values and update the project files to take the changes effects.

If your application has the SSL Enabled, IISExpressSSLPort will have the values specified for the SSL  port number.

IISPortEnabled thumb1 5 Internal things that you should know about IIS Express

#2 : Where is the configuration settings related to bindings and virtual directory?

Project files have the information related to the IIS Express and it’s basic settings; whereas there are several configuration files that are required to host and run a web application.  You can find all the IIS Express related files under \users\<username>\My Documents \ IISExpress\Config .

IISExpressConfigFiles thumb 5 Internal things that you should know about IIS Express

Open the “applicationhost.config” file in any text editor, and search for your web application name. You will find a section similar to the image shown in below.

ConfigurationSettings thumb 5 Internal things that you should know about IIS Express

As you can see this section contains the information related with the physical path of  IIS Express Virtual Directory, application pool  and the several bindings information.

The aplicationhost.config files are user specific.

#3 :  Applying Multiple Bindings With IIS Express

You can add additional bindings within the “bindings” elements to access your sites using different urls.

<bindings>
<binding protocol="http" bindingInformation="*:53294:localhost" />
<binding protocol="http" bindingInformation="*:53295:my-pc" />
<binding protocol="https" bindingInformation="*:44302:localhost" />
</bindings>

For an example if you have the above bindings in the binding configuration section, you will be able to acess the site using http://my-pc:53259 ( where my-pc has to be configure in your host files )

#4 : There is an additional application – IISExpressTray

When you press F5 to run the project, Visual Studio automatically launches the IIS Express and it will show up in your task-bar tray while it’s running.

 5 Internal things that you should know about IIS Express

You can right-click and  select the “Application”  to get the list of currently active URL’s for the current application.  To navigate, you have to click on the site URL.

IISApplicationHost thumb 5 Internal things that you should know about IIS Express

Along with the hosting sites, IIS Express ( IISExpress.exe)  is the parent process of an another application “IISExpressTray.Exe”. You can launch this application by just right click on IIS Express Icon on system tray icon and then select “Show All Applications” .

Following snaps shows the overall process hierarchy of IIS Express with in Visual Studio.

IISExpressTray thumb 5 Internal things that you should know about IIS Express

#5 : Quick way to get the details of the site configurations

From the application url lists, you can select any of the url / sites ; IISExpress tray application will show you different additional details such as runtime, application path and configuration file as shown the below image.

ApplicationDetails thumb 5 Internal things that you should know about IIS Express

This is the easiest option to open the application configuration file for IIS Express.

That’s all ! Hope going forward this information will help you to work with IIS Express.

Thanks

[Dev Tip] ASP.NET Web Api: Unwrapping HTTP Error Results and Model State Dictionaries Client-Side

When working with ASP.NET Web Api from a .NET client, one of the more confounding things can be handling the case where errors are returned from the Api. Specifically, unwrapping the various types of errors which may be returned from a specific API action method, and translating the error content into meaningful information for use be the client.

How we handle the various types of errors that may be returned to our Api client applications can be very dependent upon specific application needs, and indeed, the type of client we are building.

In this post we’ll look at some general types of issues we might run into when handing error results client-side, and hopefully find some insight we can apply to specific cases as they arise.

Understanding HTTP Response Creation in the ApiController

Most Web Api Action methods will return one of the following:

  • Void: If the action method returns void, the HTTP Response created by ASP.NET Web Api will have a 204 status code, meaning “no content.”
  • HttpResponseMessage: If the Action method returns an HttpResponseMessage, then the value will be converted directly into an HTTP response message. We can use the Request.CreateResponse()method to create instances of HttpResponseMessage, and we can optionally pass domain models as a method argument, which will then be serialized as part of the resulting HTTP response message.
  • IHttpActionResult: Introduced with ASP.NET Web API 2.0, the IHttpActionResult interface provides a handy abstraction over the mechanics of creating an HttpResponseMessage. Also, there are a host of pre-defined implementations for IHttpActionResult defined in System.Web.Http.Results, and theApiController class provides helper methods which return various forms of IHttpActionResult, usable directly within the controller.
  • Other Type: Any other return type will need to be serialized using an appropriate media formatter.

For more details on the above, see Action Results in Web API 2 by Mike Wasson.

From Web Api 2.0 onward, the recommended return type for most Web Api Action methods is IHttpActionResult unless this type simply doesn’t make sense.

Create a New ASP.NET Web Api Project in Visual Studio

To keep things general and basic, let’s start by spinning up a standard ASP.NET Web Api project using the default Visual Studio Template. If you are new to Web Api, take a moment to review the basics, and get familiar with the project structure and where things live.

Make sure to update the Nuget packages after you create the project.

Create a Basic Console Client Application

Next, let’s put together a very rudimentary client application. Open another instance of Visual Studio, and create a new Console application. Then, use the Nuget package manager to install the ASP.NET Web Api Client Libraries into the solution.

We’re going to use the simple Register() method as our starting point to see how we might need to unwrap some errors in order to create a more useful error handling model on the client side.

The Register Method from the Account Controller

If we return to our Web Api project and examine the Register() method, we see the following:

The Register() method from AccountController:
[AllowAnonymous]
[Route("Register")]
public async Task<IHttpActionResult> Register(RegisterBindingModel model)
{
    if (!ModelState.IsValid)
    {
        return BadRequest(ModelState);
    }

    var user = new ApplicationUser() 
    { 
        UserName = model.Email, 
        Email = model.Email 
    };

    IdentityResult result = await UserManager.CreateAsync(user, model.Password);

    if (!result.Succeeded)
    {
        return GetErrorResult(result);
    }
    return Ok();
}

In the above, we can see that there are a number of options for what might be returned as ourIHttpActionResult.

First, if the Model state is invalid, the BadRequest() helper method defined as part of the ApiController class will be called, and will be passed the current ModelStateDictionary. This represents simple validation, and no additional processes or database requests have been called.

If the Mode State is valid, the CreateAsync() method of the UserManager is called, returning anIdentityResult. If the Succeeded property is not true, then GetErrorResult() is called, and passed the result of the call to CreateAsync().

GetErrorResult() is a handy helper method which returns the appropriate IHttpActionResult for a given error condition.

The GetErrorResult Method from AccountController
private IHttpActionResult GetErrorResult(IdentityResult result)
{
    if (result == null)
    {
        return InternalServerError();
    }
    if (!result.Succeeded)
    {
        if (result.Errors != null)
        {
            foreach (string error in result.Errors)
            {
                ModelState.AddModelError("", error);
            }
        }
        if (ModelState.IsValid)
        {
            // No ModelState errors are available to send, 
            // so just return an empty BadRequest.
            return BadRequest();
        }
        return BadRequest(ModelState);
    }
    return null;
}

From the above, we can see we might get back a number of different responses, each with a slightly different content, which should assist the client in determining what went wrong.

Making a Flawed Request – Validation Errors

So, let’s see some of the ways things can go wrong when making a simple POST request to the Register() method from our Console client application.

Add the following code to the console application. Note that we are intentionally making a flawed request. We will pass a valid password and a matching confirmation password, but we will pass an invalid email address. We know that Web Api will not like this, and should kick back a Model State Error as a result.

Flawed Request Code for the Console Client Application:
static void Main(string[] args)
{
    // This is not a valid email address, so the POST should fail:
    string email = "john";
    string password = "Password@123";
    string confirmPassword = "Password@123";

    HttpResponseMessage result = 
        Register(email, password, confirmPassword);

    if(result.IsSuccessStatusCode)
    {
        Console.WriteLine(
            "The new user {0} has been successfully added.", email);
    }
    else
    {
        Console.WriteLine(result.ReasonPhrase);
    }
    Console.Read();
}


public static HttpResponseMessage Register(
    string email, string password, string confirmPassword)
{
    //Attempt to register:
    using (var client = new HttpClient())
    {
        var response =
            client.PostAsJsonAsync("http://localhost:51137/api/Account/Register",

            // Pass in an anonymous object that maps to the expected 
            // RegisterUserBindingModel defined as the method parameter 
            // for the Register method on the API:
            new
            {
                Email = email,
                Password = password,
                ConfirmPassword = confirmPassword
            }).Result;
        return response;
    }
}

If we run our Web Api application, wait for it to spin up, and then run our console app, we see the following output:

Console output from the flawed request:
Bad Request

Well, that’s not very helpful.

If we de-serialize the response content to a string, we see there is more information to be had. Update the Main()method as follows:

De-serialize the Response Content:
static void Main(string[] args)
{
    // This is not a valid email address, so the POST should fail:
    string email = "john";
    string password = "Password@123";
    string confirmPassword = "Password@123";

    HttpResponseMessage result = 
        Register(email, password, confirmPassword);

    if(result.IsSuccessStatusCode)
    {
        Console.WriteLine(
            "The new user {0} has been successfully added.", email);
    }
    else
    {
        string content = result.Content.ReadAsStringAsync().Result;
        Console.WriteLine(content);
    }
    Console.Read();
}

Now, if we run the Console application again, we see the following output:

Output from the Console Application with De-Serialized Response Content:
{"Message":"The request is invalid.","ModelState":{"":["Email 'john' is invalid."]}}

Now, what we see above is JSON. Clearly the JSON object contains a Message property and a ModelStateproperty. But the ModelState property, itself another JSON object, contains an unnamed property, an array containing the error which occurred when validating the model.

Since a JSON object is essentially nothing but a set of key/value pairs, we would normally expect to be able to unroll a JSON object into a Dictionary<string, object>. However, the nameless property(ies) enumerated in the ModelState dictionary on the server side makes this challenging.

Unwrapping such an object using the Newtonsoft.Json library is doable, but slightly painful. Equally important, an error returned from our API may, or may not have a ModelState dictionary associated with it.

Another Flawed Request – More Validation Errors

Say we figured out that we need to provide a valid email address when we submit our request to the Register()method. Suppose instead, we are not paying attention and instead enter two slightly different passwords, and also forget that passwords have a minimum length.

Modify the code in the Main() method again as follows:

Flawed Request with Password Mismatch:
{
    "Message":"The request is invalid.",
    "ModelState": {
        "model.Password": [
            "The Password must be at least 6 characters long."],
        "model.ConfirmPassword": [
            "The password and confirmation password do not match."]
    }
}

In this case, it appears the items in the ModelState Dictionary are represented by valid key/value pairs, and the value for each key is an array.

Server Errors and Exceptions

We’ve seen a few examples of what can happen when the model we are passing with our POST request is invalid. But what happens if our Api is unavailable?

Let’s pretend we finally managed to get our email and our passwords correct, but now the server is off-line.

Stop the Web Api application, and then re-run the Console application. Of course, after a reasonable server time-out, our client application throws an AggregateException.

What’s an AggregateException? Well, it is what we get when an exception occurs during execution of an asyncmethod. If we pretend we don’t know WHY our request failed, we would need to dig down into theInnerExceptions property of the AggregateException to find some useful information.

In the context of our rudimentary Console application, we will implement some top-level exception handling so that our Console can report the results of any exceptions like this to us.

Update the Main() method once again, as follows:

Add Exception Handling to the Main() Method of the Console Application:
static void Main(string[] args)
{
    // This is not a valid email address, so the POST should fail:
    string email = "john@example.com";
    string password = "Password@123";
    string confirmPassword = "Password@123";

    // Add a Try/Catch in case something goes wrong and the server throws:
    try
    {
        HttpResponseMessage result =
            Register(email, password, confirmPassword);

        if (result.IsSuccessStatusCode)
        {
            Console.WriteLine(
                "The new user {0} has been successfully added.", email);
        }
        else
        {
            string content = result.Content.ReadAsStringAsync().Result;
            Console.WriteLine(content);
        }
    }
    catch (AggregateException ex)
    {
        Console.WriteLine("One or more exceptions has occurred:");
        foreach (var exception in ex.InnerExceptions)
        {
            Console.WriteLine("  " + exception.Message);
        }
    }
    Console.Read();
}

If we run our console app now, while our Web Api application is offline, we get the following result:

Console Output with Exception Handling and Server Time-Out:
One or more exceptions has occurred:
  An error occurred while sending the request.

Here, we are informed that “An error occurred while sending the request” which at least tells us something, and averts the application crashing due to an unhandled AggregateException.

Unwrapping and Handling Errors and Exceptions in Web Api

We’ve seen a few different varieties of errors and exceptions which may arise when registering a user from our client application.

While outputting JSON from the response content is somewhat helpful, I doubt it’s what we are looking for as Console output. What we need is a way to unwrap the various types of response content, and display useful console messages in a clean, concise format that is useful to the user.

While I was putting together a more in-depth, interactive console project for a future article, I implemented a custom exception, and a special method to handle these cases.

ApiException – a Custom Exception for Api Errors

Yeah, yeah, I know. Some of the cases above don’t technically represent “Exceptions” by the hallowed definition of the term. In the case of a simple console application, however, a simple, exception-based system makes sense. Further, unwrapping all of our Api errors up behind a single abstraction makes it easy to demonstrate how to unwrap them.

Mileage may vary according to the specific needs of YOUR application. Obviously, GUI-based applications may extend or expand upon this approach, relying less on Try/Catch and throwing exceptions, and more upon the specifics of the GUI elements available.

Add a class named ApiException to the Console project, and add the following code:

ApiException – a Custom Exception
using System;
using System.Collections.Generic;
using System.Linq;
using System.Net;
using System.Net.Http;

namespace ApiWithErrorsTest
{
    public class ApiException : Exception
    {
        public HttpResponseMessage Response { get; set; }
        public ApiException(HttpResponseMessage response)
        {
            this.Response = response;
        }


        public HttpStatusCode StatusCode
        {
            get
            {
                return this.Response.StatusCode;
            }
        }


        public IEnumerable<string> Errors
        {
            get
            {
                return this.Data.Values.Cast<string>().ToList();
            }
        }
    }
}

Unwrapping Error Responses and Model State Dictionaries

Next, let’s add a method to our Program which accepts an HttpResponseMessage as a method argument, and returns an instance of ApiException. Add the following code the the Program class of the Console application:

Add the CreateApiException Method the to Program Class:
public static ApiException CreateApiException(HttpResponseMessage response)
{
    var httpErrorObject = response.Content.ReadAsStringAsync().Result;

    // Create an anonymous object to use as the template for deserialization:
    var anonymousErrorObject = 
        new { message = "", ModelState = new Dictionary<string, string[]>() };

    // Deserialize:
    var deserializedErrorObject = 
        JsonConvert.DeserializeAnonymousType(httpErrorObject, anonymousErrorObject);

    // Now wrap into an exception which best fullfills the needs of your application:
    var ex = new ApiException(response);

    // Sometimes, there may be Model Errors:
    if (deserializedErrorObject.ModelState != null)
    {
        var errors = 
            deserializedErrorObject.ModelState
                                    .Select(kvp => string.Join(". ", kvp.Value));
        for (int i = 0; i < errors.Count(); i++)
        {
            // Wrap the errors up into the base Exception.Data Dictionary:
            ex.Data.Add(i, errors.ElementAt(i));
        }
    }
    // Othertimes, there may not be Model Errors:
    else
    {
        var error = 
            JsonConvert.DeserializeObject<Dictionary<string, string>>(httpErrorObject);
        foreach (var kvp in error)
        {
            // Wrap the errors up into the base Exception.Data Dictionary:
            ex.Data.Add(kvp.Key, kvp.Value);
        }
    }
    return ex;
}

In the above, we get a sense for what goes into unwrapping an HttpResponseMessage which contains a mode state dictionary.

When the response content includes a property named ModeState, we unwind the ModelState dictionary using the magic of LINQ. We knit the string key together with the contents of the value array for each item present, and then add each item to the exception Data dictionary using an integer index for the key.

If no ModelState property is present in the response content, we simply unwrap the other errors present, and add them to the Data dictionary of the exception.

Error and Exception Handling in the Example Application

We’ve already added some minimal exception handling at the top level of our application. Namely, we have caught and handled AggregateExceptions which may be thrown by async calls to our api, which are not handled deeper in the call stack.

Now that we have added a custom exception, and a method for unwinding certain types error responses, let’s add some additional exception handling, and see if we can do a little better, farther down.

Update the Register() method as follows:

Add Handle Errors in the Register() Method:
public static HttpResponseMessage Register(
    string email, string password, string confirmPassword)
{
    //Attempt to register:
    using (var client = new HttpClient())
    {
        var response =
            client.PostAsJsonAsync("http://localhost:51137/api/Account/Register",

            // Pass in an anonymous object that maps to the expected 
            // RegisterUserBindingModel defined as the method parameter 
            // for the Register method on the API:
            new
            {
                Email = email,
                Password = password,
                ConfirmPassword = confirmPassword
            }).Result;

        if(!response.IsSuccessStatusCode)
        {
            // Unwrap the response and throw as an Api Exception:
            var ex = CreateApiException(response);
            throw ex;
        }
        return response;
    }
}

You can see here, we are examining the HttpStatusCode associated with the response, and if it is anything other than successful, we call our CreateApiException() method, grab the new ApiException, and then throw.

In reality, for this simple console example we likely could have gotten by with creating a plain oldSystem.Exception instead of a custom Exception implementation. However, for anything other than the simplest of cases, the ApiException will contain useful additional information.

Also, the fact that it is a custom exception allows us to catch ApiException and handle it specifically, as we will probably want our application to behave differently in response to an error condition in an Api response than we would other exceptions.

Now, all we need to do (for our super-simple example client, anyway) is handle ApiException specifically in ourMain() method.

Catch ApiException in Main() Method

Now we want to be able to catch any flying ApiExceptions in Main(). Our Console application, shining example of architecture and complex design requirements that it is, pretty much only needs a single point of error handling to properly unwrap exceptions and write them out as console text!

Add the following code to Main() :

Handle ApiException in the Main() Method:
static void Main(string[] args)
{
    // This is not a valid email address, so the POST should fail:
    string email = "john@example.com";
    string password = "Password@123";
    string confirmPassword = "Password@123";

    // Add a Try/Cathc in case something goes wrong and the server throws:
    try
    {
        HttpResponseMessage result =
            Register(email, password, confirmPassword);

        if (result.IsSuccessStatusCode)
        {
            Console.WriteLine(
                "The new user {0} has been successfully added.", email);
        }
        else
        {
            string content = result.Content.ReadAsStringAsync().Result;
            Console.WriteLine(content);
        }
    }
    catch (AggregateException ex)
    {
        Console.WriteLine("One or more exceptions has occurred:");
        foreach (var exception in ex.InnerExceptions)
        {
            Console.WriteLine("  " + exception.Message);
        }
    }
    catch(ApiException apiEx)
    {
        var sb = new StringBuilder();
        sb.AppendLine("  An Error Occurred:");
        sb.AppendLine(string.Format("    Status Code: {0}", apiEx.StatusCode.ToString()));
        sb.AppendLine("    Errors:");
        foreach (var error in apiEx.Errors)
        {
            sb.AppendLine("      " + error);
        }
        // Write the error info to the console:
        Console.WriteLine(sb.ToString());
    }
    Console.Read();
}

All we are doing in the above is unwinding the ApiException and transforming the contents for the Data dictionary into console output (with some pretty hackey indentation).

Now let’s see how it all works.

Running Through More Error Scenarios with Error and Exception Handling

Stepping all the way back to the beginning, lets see what happens now if we try to register a user with an invalid email address.

Change our registration values in Main() back to the following:

// This is not a valid email address, so the POST should fail:
string email = "john";
string password = "Password@123";
string confirmPassword = "Password@123";

Run the Web Api application once more. Once it has properly started, run the Console application with the modified registration values. The output to the console should look like this:

Register a User with Invalid Email Address:
An Error Occurred:
Status Code: BadRequest
Errors:
  Email 'john' is invalid.

Similarly, if we use a valid email address, but password values which are both too short, and also do not match, we get the following output:

Register a User with Invalid Password:
An Error Occurred:
Status Code: BadRequest
Errors:
  The Password must be at least 6 characters long.
  The password and confirmation password do not match.

Finally, let’s see what happens if we attempt to register the same user more than once.

Change the registration values to the following:

Using Valid Registration Values:
string email = "john@example.com";
string password = "Password@123";
string confirmPassword = "Password@123";

Now, run the console application twice in a row. The first time, the console output should be:

Console Output from Successful User Registration:
The new user john@example.com has been successfully added.

The next time, however, an error result is returned from our Web Api:

Console Output from Duplicate User Registration:
An Error Occurred:
Status Code: BadRequest
Errors:
  Name john@example.com is already taken.. Email 'simon@example.com' is already taken.

Oh No You did NOT Use Exceptions to Deal with Api Errors!!

Oh, yes I did . . . at least, in this case. This is a simple, console-based application in which nearly every result needs to end up as text output. Also, I’m just a rebel like that, I guess. Sometimes.

The important thing to realize is how to get the information we need out of the JSON which makes up the response content, and that is not as straightforward as it may seem in this case. How different errors are dealt with will, as always, need to be addressed within terms best suited for your application.

In a good many cases, treating Api errors as exceptions, to me, has merit. Doing so most likely will rub some architecture purists the wrong way (many of the errors incoming in response content don’t really meet the textbook definition of “exception“). That said, for less complex .NET-based Api Client applications, unwrapping the errors from the response content, and throwing as exceptions to be caught by an appropriate handler can save on a lot of duplicate code, and provides a known mechanism for handling problems.

In other cases, or for your own purposes, you may choose to re-work the code above to pull out what you need from the incoming error response, but otherwise deal with the errors without using exceptions. Register() (and whatever other methods you use to call into your Api) might, in the case of a simple console application, return strings, ready for output. In this case, you could side-step the exception issue.

Needless to say, a good bit of the time, you will likely by calling into your Web Api application not from a desktop .NET application, but instead from a web client, probably using Ajax or something.

That’s a Long and Crazy Post about Dealing with Errors – Wtf?

Well, I am building out a more complex, interactive console-based application in order to demo some concepts in upcoming posts. One of the more irritating aspects of that process was figuring out a reasonable way to deal with the various issues that may arise, when all one has to work with is a command line interface to report output to the user.

This was part of that solution (ok, in the application I’m building, things are a little more complex, a little more organized, and there’s more to it. But here we saw some of the basics).

But . . . Can’t We Just do it Differently on the Server?

Well . . . YES!

In all likelihood, you just might tune up how and what you are pushing out to the client, depending upon the nature of your Web Api and the expected client use case. In this post, I went with the basic, default set-up (and really, we only looked at one method). But, depending upon how your Api will be used, you might very will handle errors and exceptions differently on the server side, which may impact how you handle things on the client side.

REF: http://typecastexception.com/post/2014/09/28/ASPNET-Web-Api-Unwrapping-HTTP-Error-Results-and-Model-State-Dictionaries-Client-Side.aspx

[Dev Tip] Interact With the Web in Real-time Using Arduino, Firebase and Angular.js

This simple project is meant to be a hybrid introduction to connecting and manipulating data over the internet with Arduino, Node, Angular and Firebase.

The Internet of Things is nothing new. You may have been using it all along. In the broadest sense, your laptop and smartphones are IoT objects. What’s actually new is the “T” part. We have been using computers and smartphones so often that we hardly recognize them as “things.” However, “things” are more synonymous to everyday objects such as clothes, furnitures, fridges, clocks, books, lamps, skateboards, bicycles, and etc. IoT is when a coffee machine that brews you a cup of java when the weather gets too cold, a pair of shoes that lights up 10 minutes before your train arrives, or a door knob that alerts your phone when your parents try to trespass into your room.

To be able to connect to the internet, make sense of its data and interact with the users, these things need tiny computers aka micro controllers to make them conscious.

What we are building

We are going to connect an Arduino board to the internet and change the RGB color property on a web page in real-time by rotating a potentiometer.

What we need:

  • Arduino Uno
  • A-B USB cable
  • Potentiometer (aka pot)
  • RGB LED
  • 330 Ohms resistors x 3
  • 10 KOhms resistor x 1
  • Male-to-male jumper wires x 9

Everything is included in Sparkfun’s inventor’s kit, which is quite neat to get your hands on. No wifi or ethernet shield needed, since we’re actually persisting the data to the online database and communicate with the web app via the REST API provided by Firebase.

If you have not installed Node, head to Node.js home and follow instructions to install Node and npm.

All the codes can be downloaded from my repo or cloned using git:

$ git clone https://github.com/jochasinga/firepot

Once downloaded, cd firepot to get into the directory, and you should see two subdirectories—pot and app. cd into each one and install the dependencies:

$ cd pot && npm install

All dependencies are indicated in package.json, and npm automatically install them according to the information. They will be collected in a new subdirectory node_modules and can be required by any code within the project scope.

Connecting the circuit

Image made with Fritzing

Connect your circuit according to the diagram. A typical potentiometer has three leads. Connect one end to +5V power via 10 KOhms pull-up resistor and the other far end to ground (0V). The pot provides variable resistance between the voltage, and the middle lead should be connected to Arduino’s analog input pin (A0) to feed the voltage signal into the Arduino.

RGB LED is essentially three LEDs in one, each with different color of red, green and blue, together producing 16,777,216 possible colors. We are going to use the pot to traverse this color range from pure red (#FF0000) to blue (#0000FF) to green (#00FF00) and back to red again. The longest lead of the LED is called a common, and should be connected to ground. The rest are connected to Arduino’s PWM outputs (those with ~ preceding the number). The code connects red, green and blue leads to ~9, ~10 and ~11 respectively.

Connect the Arduino to your laptop via the USB cable, and you’re good to go.

Signing up with Firebase

Firebase is a JSON-style database service for real-time applications (You’ll need a free signup to use). Firebase implements a clever way of manipulating JSON data by adopting RESTful APIs. In this project, we will CREATE, READ and UPDATE a data chunk that looks like this:

"colors" : {
  "r" : 255,
  "g" : 0,
  "b" : 0
}

Firebase has an easy way of getting to your data via REST api, i.e. you can get your JSON data at https://burning-limbo-6666.firebaseio.com/colors.json,where https://burning-limbo-6666.firebaseio.com is the domain address of your app which Firebase generates for you after creating a new app, and /colors is the parent node of your data. Firebase has a data dashboard at the very URL, so you can just paste the address into the browser and hit it after you’ve updated the data there in the next section to see your data changed by the pot in real-time.

The Firebase “Forge” Dashboard displaying JSON data in tree format.

pot.js

Johnny-five is a javaScript library that wraps around Arduino’s C/C++ language and interface with the board via Firmata firmware, created by the awesome Rick Waldron, and is synonymous to the Nodebot Movement. In order to make it work, you must open the Arduino IDE to flash a standard Firmata code onto the board. On your IDE, go to File > Examples > Firmata > StandardFirmata and upload the code (Don’t forget to select the right board and serial port in the Tools menu). Once the upload have finished, you can close the IDE. Now, let’s have a look at our pot.js code.

https://gist.github.com/jochasinga/dad3e88b765893721c43

First, (1–3) we require our installed dependencies for the app, firebase andjohnny-five, then we (5–8) create a new firebase reference firebaseRef to where your data is stored. After that, (10) we create a new johnny-five instance of the Arduino board, and hook it to a callback function which will execute the rest of the code once it’s ready. (11–13) I assign the max value we expect from the pot to a variable and divide it by the RGB color subrange number to obtain a standard offset “distance” used as a step variable to calculate where the output value from the pot is on the RGB strip i.e. offset is MAGENTA, offset * 2 is BLUE, offset * 3 is CYAN and so on. You can see how I divided the RGB color strip into 6 subranges, as graphically shown below.

RGB Strip divided into 6 ranges

Normally on 5V power, a pot will convert analog signal (0–5V) to digital and give out a range of integer from 0–1023. In my case, my little pot maxes at half of that, so my maxValue lies somewhere around 511(Check this value by logging the output with console.log()). Then (16–19), create a new instance of the pot sensor, set its analog pin to A0 and frequency to 250. (22) Assign each LED’s pin to an array variable. Now, (25++) set our pot instance to listen to the “data” event, and within the callback function is the rest of the code that (27–40)calculates and maps the pot’s output range (0-maxValue) to a range of 0–255 (LED’s brightness)using our obtained step variable offset. (44–1o2) I use switch-case loop to conditionally adjusts each LED’s color brightness with Led.brightness method and saving these values to Firebase with Firebase.set method according to where the pot value is.

After that, run pot.js with node commandline

$ node pot.js

Your LED should light up and your terminal should be loop-printing the value from the pot (self) and which loop (or subrange) your pot value is currently in. Try spinning the pot to see the printed data changed as the LED’s color gradually shift. Then, browse to your Firebase dashboard using your app’s URL (i.e. https://burning-limbo-6666.firebaseio.com/colors). You should see your data change as you rotate your pot. We have successfully CREATEd and UPDATEd data on a database like you would have done with web forms, sliders or buttons. That concludes the hardware side.

app.js

Now we are going to work on our client, a simple web app. The structure of the app directory is as follow:

app
├── app.js
├── node_modules
|   ├── express
|   ├── firebase
|   └── socket.io
├── package.json
└── public
    ├── index.html    
    └── index.js

If you have not installed dependencies, you will probably not seenode_modules subdirectory in there. Do so now using npm install.

$ cd app && npm install

Take note of the public directory. app.js is a server code which serve static contents from public directory, in this case, index.html and index.js. Let’s hop into app.js:

https://gist.github.com/jochasinga/63ceadc19c5139f55660

What this code does is (5–18) creating a Node web server to listen to requests on port 3000 and (21)serve the front-end contents from insidepublic directory. Then (24–25) the server waits for a socket connection (i.e. GET request), print out “Connect and ready!” message, and (29++) start tracking data from Firebase and printing out changes. Firebase is not necessary here, since we will be using Angularfire library in public/index.js to sync data from Firebase directly there, but it’s intentionally included in here to exhibit a basic firebase method of detecting data changes and retrieving the snapshot of them. The most important part here is serving thepublic/index.html page and run script in public/index.js.

index.html

What our web page will look like

Our web page will be displaying R : G : B values dynamically from Firebase and changing the background color of the div according to how you rotate your pot. We’re going to use AngularFire, Firebase client library supporting Angular.js.

https://gist.github.com/jochasinga/c720677640e026381366

This html view(V) binds its part to a data model(M) that syncs data from your Firebase storage, and as data change, only that part is re-rendered. Angular operates on what’s called a “directive.” Directives add new functionalities to HTML elements instead of manipulating the DOM as in JQuery. (3) ng-app directive starts the application and defines the scope of the binding, (7) ng-controller defines the application controller(C) and scope that that particular controller method has effect on, and (10) ng-style allows dynamic styling of document (like you would have done with JQuery’s .cssor .addClass). To display data from the model, double-brackets ({{ }}) is used to contain the variable, which is a common way to do it in other web frameworks’ template language. Never mind the data object for now, you’ll see it in public/index.js. Ensure that you have included the scripts before</body>.

index.js

This is the engine room of our front end. In this file, we attach the firebase module to the app, define the controller method and sync the data from firebase to a local model object used by the html binding.

https://medium.com/media/b553c12c2bf5c868a4e4552debb06709?maxWidth=700

https://gist.github.com/jochasinga/e51c240a33f9704b3030

(2) Register firebase service to Angular app. After that, (5) you’ll have$firebase variable available for injecting into the controller. (6–9) Setting up the first part of the controller method is familiar—we create a firebase reference to our data. Now, (11) use the reference as a parameter to$firebase() to create an Angularfire reference to the data. (14)We translate the data into a JavaScript object, and (17) bind it to the variable “data” that will be used in index.html template.

Whew! That was some work, right? Now comes the exciting part. Go back topot directory and run your pot code again with:

$ node pot.js

Once you’ve got your LED turned on and the pot value start printing to the console, from another terminal window, run your app.js inside app directory:

$ node app.js

The console should start by printing “Server listening on port 3000″ then gushing out RGB values from Firebase. Go to your web browser and browser to http://localhost:3000, hopefully, you’ll get like the video below.

https://vine.co/v/OqXhOUWAY6I

If you like this article, please recommend and retweet. Feel free to shoot me at jo.chasinga@gmail.com. I’m up for talking, exchanging ideas, collaborations or consults. Comments are welcomed.

[Discovery] Lịch sử hình thành và phát triển của công nghệ màn hình cảm ứng

banner copy.

Hiện nay, một thiết bị di động với màn hình cảm ứng đa điểm đã trở thành sản phẩm quá đỗi quen thuộc với mỗi người chúng ta. Có thể bắt gặp màn hình cảm ứng trên smartphone, máy tính bảng,… ở khắp mọi nơi trong cuộc sống hàng ngày. Vậy có bao giờ bạn tự hỏi chính xác màn hình cảm ứng được phát triển từ bao giờ? Như thế nào và do ai sáng chế? Do đó, chuyên mục “mỗi tuần 1 phát minh” lần này sẽ cùng các bạn đi tìm câu trả lời cho những thắc mắc nói trên.

Một sự kiện quan trọng trong quá trình hình thành và phát triển của công nghệ màn hình cảm ứng

lich_su_man_hinh_cam_ung_1.

Mở đầu…

Những năm gần đây, chúng ta đã chứng kiến sự phát triển vượt bậc của khoa học công nghệ kỹ thuật số. Cách đây chỉ 7 năm, những chiếc smartphone mà con người chỉ dám mơ thì bây giờ đang hiện diện ở khắp mọi nơi trên thế giới và trở thành một trong những ngành công nghiệp có mức khả năng sinh lợi cao nhất hành tinh. Một hệ quả ở đây, nếu chỉ chậm cập nhật thông tin trong thời gian ngắn, chúng ta có thể sẽ bỏ lỡ những cuộc cách mạng quan trọng đối với giới công nghệ đang manh nha diễn ra từng ngày.

Hiện nay, màn hình cảm ứng đa điểm tương ứng giao diện người dùng được xem như một công cụ chính giúp con người có thể tương tác với các thiết bị kỹ thuật số. Theo dự đoán của các chuyên gia, đây sẽ là xu hướng chủ đạo chi phối sự phát triển của các thiết bị điện tử và sự hiện diện của chuột, bàn phím cũng sẽ dần lu mờ. Màn hình cảm ứng đã dần thống trị thế giới thiết bị di động và còn sẵn sàng được áp dụng cho nhiều thiết bị khác. Bài viết sau sẽ điểm qua một số cột mốc quan trọng của màn hình cảm ứng nhằm trả lời cho câu hỏi nó xuất hiện từ đâu và như thế nào?

Đầu tiên, hãy dành ít phút xem lại đoạn video dưới đây (từ phút 15:15)

​Chắc hẳn bạn không còn xa lạ gì đối với người trong video, Steve Jobs đang giới thiệu chiếc iPhone thế hệ đầu tiên vào ngày 9 tháng 1 năm 2007. Trong đoạn video, ngay thấy được thao tác “trượt để mở khóa” hay “vuốt để cuộn”, ca khán phòng đã tràn những tiếng vỗ tay và hò reo. Đó là lần đầu tiên họ thấy được một thiết bị có khả năng như vậy.

Đây là sự kiện đã thay đổi hoàn toàn suy nghĩ của tất cả chúng ta về một chiếc màn hình di động. Rõ ràng, các thao tác demo thử chiếc iPhone với màn hình cảm ứng mượt mà đã hớp hồn tất cả mọi người. Những thao tác căn bản, đơn giản được thực hiện ngay trên màn hình mang lại giá trị hết sức thiết thực cho người dùng. Thế nhưng, có phải mãi tới năm 2007 thì màn hình cảm ứng mới xuất hiện? Trước đó có màn hình cảm ứng nào không?

Những năm 1960: Màn hình cảm ứng đầu tiên

touch--1352711727_500x0. Chiếc màn hình cảm ứng đầu tiên do Johnson phát triển (ảnh chụp năm 1967)​

Các nhà sử học đã khẳng định rằng, chiếc màn hình điều khiển bằng cách chạm ngón tay đầu tiên trên thế giới được phát minh bởi E.A. Johnson vào năm 1965 tại Royal Radar Establishment ở thị trấn Malvern, vùng Worcestershire nước Anh. Johnson đã diễn tả phát minh của mình trong một báo cáo đăng tải trên tạp chí Electronics Letter với tựa đề: “Màn hình chạm – một thiết bị đầu cuối kỳ diệu dành cho máy tính.” Đồng thời, báo cáo cũng dùng một sơ đồ để diễn tả cơ chế nhận diện cảm ứng của công nghệ màn hình do Johnson phát minh – Công nghệ mà ngày nay chúng ta thường nhắc đến với tên gọi Màn hình cảm ứng điện dung.

Chiếc màn hình cảm ứng đầu tiên này đã được sử dụng cho hệ thống radar tại Đài kiểm soát không lưu thuộc Royal Radar Establishment. Một thiết bị khá cồng kềnh, hoạt động chậm, độ nhạy kém, thiếu chính xác và giá thành khá tốn kém. 2 năm sau đó, Johnson tiếp tục diễn tả công nghệ trên trong một báo cáo khác đăng tải trên tạp chí Ergonomics vào năm 1967 với tiêu đề “Màn hình cảm ứng: Một giao diện Con người – Máy tính được lập trình sẵn.”

man_hinh_cam_ung_dien_tro.dien_dung. Nguyên lý hoạt động cơ bản của thế hệ màn hình điện dung đầu tiên​

Thế hệ màn hình cảm ứng điện dung đầu tiên của Johnson có cấu tạo không quá phức tạp. Đó là một bảng điều khiển được làm từ vật liệu cách điện (thủy tinh), bề mặt bao phủ chất dẫn điện trong suốt làm bằng Indi thiếc oxit (ITO). Phần “dẫn điện” thường được đảm nhận bởi ngón tay của con người. Khi người dùng chạm tay lên màn hình, sự hút điện giữa bàn tay và màn hình làm các tụ điện tại vị trí tiếp xúc mất điện kéo theo giá trị điện dung cũng thay đổi theo.

Bằng cách đo lường sự thay đổi giá trị điện dung tại mỗi 4 góc màn hình, hệ thống có thể xác định được vị trí của điểm cảm ứng và báo về máy tính trung tâm để dịch ra thành lệnh tương ứng. Dạng màn hình cảm ứng điện dung này hoạt động chưa thật sự chính xác và chỉ xử lý được lệnh điều khiển 1 chạm tại 1 thời điểm. Hơn nữa, thao tác chạm cũng đặc biệt đơn giản: hoặc là chạm, hoặc là không. Chỉ tới thời gian sau này thì khả năng cảm nhận mức độ của áp lực mới được bổ sung vào màn hình điện dung. Dù vậy, thế hệ màn hình trên vẫn được sử dụng tại các đài kiểm soát không lưu tại Anh cho đến cuối thập niên 1990.

Những năm 1970: Màn hình cảm ứng điện trở được phát minh

Hurst. G. Samuel Hurst, người đầu tiên đề xuất ý tưởng và phát triển nguyên mẫu ban đầu của màn hình cảm ứng điện trở​

Mặc dù màn hình cảm ứng điện dung đã được ra đời đầu tiên nhưng lại nhanh chóng bị lu mờ và dần được thay thế bởi công nghệ cảm ứng điện trở. Đó là nhờ vào ý tưởng khá tình cờ của nhà phát minh người Mỹ, giáo sư G. Samuel Hurst đến từ Đại học Kentucky. Trong quá trình nghiên cứu vật lý hạt nhân, nhóm nghiên cứu cần phải sử dụng máy gia tốc hạt Van de Graff và thường phải làm việc vào ban đêm. Công việc chính của nhóm đơn giản chỉ là thực hiện các phép phân tích lặp đi lặp lại đầy tẻ nhạt. Điều này đã phần nào làm chậm đi tiến trình của công tác nghiên cứu.

Nhằm đẩy nhanh thời gian phân tích số liệu, giáo sư Hurst đã nghĩ ra phương pháp sử dụng các tấm giấy tích hợp các tụ điện nhằm đọc tọa độ XY. Chính ý tưởng này đã dẫn đến sự ra đời của màn hình cảm ứng điện trở đầu tiên cho máy tính. Với mô hình “giấy tụ điện”, giáo sư Hurst cùng đồng nghiệp của ông đã có thể thực hiện các phép tính toán trong thời gian nhanh hơn hàng chục lần so với trước đó.

Elograph_Electronic_Graphing_Device. ​Ngay sau đó, trường đại học Kentucky nhanh chóng đệ trình đơn xin cấp bằng sáng chế cho phát minh trên. Tuy nhiên, do chỉ mới được dùng trong nghiên cứu khoa học mà chưa tìm thấy ứng dụng nào khác nên bằng sáng chế đã không được công nhận. Dù vậy, giáo sư Hurst vẫn tin rằng ý tưởng của ông có thể được áp dụng vào nhiều lĩnh vực khác. Vào năm 1970, Hurst trở lại làm việc tại Phòng thí nghiệm quốc gia Oak Ridge (ORNL). Tại đây, ông cùng các nhóm các đồng nghiệp đã dành thời gian sau giờ làm việc để thực hiện các thí nghiệm.

Hurst đặt tên nhóm là Elographics (sau này cũng là tên công ty của ông) với mục tiêu hoàn thiện ý tưởng vô tình phát hiện trước đó về mảnh giấy chứa các tụ điện. Cuối cùng, nhóm đã phát hiện ra rằng hoàn toàn có thể sử dụng mảnh bìa chứa tụ điện nhằm giúp con người có thể tương tác trực tiếp với màn hình máy tính. Tất cả những gì màn hình chạm cần là 1 tấm phủ dẫn điện xếp chồng với 1 tấm bìa có hệ trục tọa độ XY bằng dây dẫn điện.

Khi có áp lực tác động lên tấm phủ, người ta sẽ đo điện áp chạy giữa dây dẫn trục X và trục Y từ đó xác định được tọa độ của điểm tiếp xúc. Phát hiện của nhóm nghiên cứu đã tạo nên công nghệ mà ngày nay chúng ta vẫn thường gọi là Màn hình cảm ứng điện trở do sự cảm ứng hoàn toàn phụ thuộc vào áp lực chứ không phải dựa trên độ dẫn điện. Cũng do đó mà màn hình trên có thể hoạt động bằng cả ngón tay người lẫn bút stylus hoặc các vật thể tương tự.

eg-372196. AccuTouch thế hệ thứ 2 do Elographics phát triển​

Màn hình cảm ứng điện trở với đặc điểm giá thành sản xuất rẻ, dễ vận hành đã nhanh chóng được đưa vào thương mại hóa trên quy mô lớn nhằm phục vụ cho nhiều lĩnh vực khác nhau. Thời điểm bấy giờ, hầu hết thiết bị và máy móc sử dụng màn hình cảm ứng điện dung có thể được bắt gặp tại các nhà hàng, nhà máy và cả bệnh viện do phù hợp với tính chất công việc của những môi trường trên cộng với giá thành không quá cao. Một số thiết bị di động trong thời gian sau đó cũng được sử dụng màn hình cảm ứng điện trở. Dù vậy, cho tới hiện nay thì thế hệ màn hình này chủ yếu bị giới hạn bởi các dòng điện thoại rẻ tiền thuộc phân khúc thấp.

Không dừng lại ở chiếc màn hình cảm ứng điện trở đầu tiên, nhóm Elographics tiếp tục nhận được bằng sáng chế cho phát minh cho màn hình cảm ứng cong đầu tiên. Bằng sáng chế mang tên “cảm biến cho hệ tọa độ phẳng” mô tả một hệ thống cảm biến giá rẻ nhằm xác định tọa độ của 1 điểm trong hệ tọa độ phẳng bằng cách đặt chồng các tấm vật liệu chứa dây dẫn mô phỏng trục X và Y.

plato-372196. Hình ảnh cỗ máy PLATO IV đang được vận hành​

Vào năm 1971, một số thiết bị có khả năng cảm ứng bắt đầu được giới thiệu. Điểm đáng chú ý là thế hệ màn hình này không sử dụng công nghệ cảm ứng điện trở lẫn điện dung. Một trong những cỗ máy có cảm ứng được sử dụng rộng rãi nhất vào thời điểm bấy giờ chính là thiết bị đầu cuối PLATO IV sử dụng tại các giảng đường tại Đại học Illinois. PLATO IV là chiếc máy tính tổng quát đầu tiên được trang bị hệ thống phần mềm hướng dẫn học tập. Bằng cách sử dụng công nghệ cảm ứng hồng ngoại, PLATO IV là chiếc màn hình máy tính đầu tiên sử dụng tại lớp học cho phép các sinh viên có thể chạm trực tiếp vào màn hình để trả lời câu hỏi.

Những năm 1980: Sự hình thành các nguyên lý quan trọng

Vào năm 1982, thiết bị điều khiển đa chạm đầu tiên được phát triển bởi Nimish Mehta tại Đại học Toronto. Tuy nhiên, hình thái ban đầu của chiếc “màn hình cảm ứng” này không giống với những gì mà chúng ta tưởng tượng ngày nay. Dựa trên ý tưởng của Mehta, nhóm các nhà nghiên cứu nhập liệu cũng thuộc đại học Toronto dẫn đầu bởi Bill Buxton đã thực tế hóa công nghệ điều khiển của Mehta vào trong chiếc màn hình cảm ứng cụ thể.

image. Bill Buxton, người có vai trò quan trọng cho sự phát triển của công nghệ cảm ứng đa điểm sau này​

Theo các nhà sử học, Buxton đóng vai trò hết sức quan trọng trong sự phát triển của công nghệ cảm ứng đa chạm. Dù vậy, Buxton vẫn tuyên bố rằng thành công đó chủ yếu là nhờ vào nghiên cứu trước đó của Mehta. Trong một báo cáo, Buxton đã mô tả khá chi tiết về hệ thống đa chạm của ông: Bề mặt chạm là một tấm nhựa gắn kết với một tấm thủy tinh. Ở giữa 2 tấm vật liệu được thắp sáng bởi bóng đèn huỳnh quang. Ngay bên dưới bề mặt là một camera có khả năng nhận diện được điểm tối trên màn hình mờ.

Khi một hoặc nhiều ngón tay chạm vào bề mặt thủy tinh, camera sẽ phát hiện ra điểm chạm dựa vào các điểm đen do đầu ngón tay để lại trên màn hình. Đồng thời, bên trong cũng được trang bị một tấm gương phản chiếu nhằm tăng cường hiệu ứng quang học. Dữ liệu đầu ra của camera được số hóa và chuyển tiếp cho bộ xử lý tín hiệu để phân tích.

videoplace_systemarchit_b. Nguyên lý hoạt động cơ bản của VideoPlace​

Không lâu sau đó, Myron Krueger, chuyên gia đồ họa máy tính tại Hoa Kỳ đã phát triển thành công hệ thống quang học có khả năng nắm bắt được chuyển động của bàn tay sau gần 10 năm nghiên cứu. Năm 1983, Krueger chính thức giới thiệu và đặt tên cho hệ thống này là Video Place (sau đó đổi tên thành Video Desk). Bằng cách sử dụng hệ thống máy chiếu và camera, Video Place có khả năng nắm bắt được chuyển động của bàn tay, ngón tay và thậm chí là cả cơ thế con người.

Khác với màn hình cảm ứng đa chạm, hệ thống của Krueger gợi cho chúng ta cảm giác tương tự như thiết bị nắm bắt cử chỉ cơ thể như Kinect hay Leaf Motion. Dĩ nhiên là Video Place không thể nào vận hành hoàn hảo như các thiết bị hiện đại ngày nay nhưng rõ ràng, đây được xem như một tầm nhìn đầy sáng tạo về tương tác giữa con người và máy tính trong tương lai. Dù vậy, Krueger cũng tiếp tục hoàn thiện các bản nâng nâng cấp của Video Place và trở thành nhà tiên phong trong lĩnh vực tương tác thực tế ảo trong những khoảng thời gian sau đó.

Thiết bị bắt chuyển động VideoPlace của Myron Krueger năm 1968​

Cũng vào khoảng đầu những năm 1980, màn hình cảm ứng bắt đầu được thương mại hóa rộng rãi tại nhiều nơi trong các lĩnh vực khác nhau. Một ví dụ điển hình là cỗ máy HP-150 do Hewlett-Packard (HP) phát triển và chính thức giới thiệu vào tháng 9 năm 1983. Đây là chiếc máy tính chạy MS-DOS với màn hình CRT 9 inch do Sony sản xuất. Viền quanh màn hình máy tính là dãy các bộ phát xạ hồng ngoại (IR) và bộ cảm bộ cảm biến có thể dò được cử chỉ chạm ngón tay vào màn hình.

800px-Hp150_touchscreen_20081129-640x480. Cỗ máy HP-150 chạy trên nền MS-DOS với màn hình cảm ứng 9 inch. (dãy các bộ phát xạ hồng ngoại (IR) chính là những lỗ chạy xung quanh màn hình)​

Cỗ máy HP-150 được bán ra với giá 2795 đô la – một cái giá không phải quá đắt đỏ. Dù vậy, HP-150 vẫn chưa được sự chấp nhận từ đại đa số người dùng do vẫn còn một số vấn đề về khả năng vận hành. Nguyên lý hoạt động chính của hệ thống cảm ứng trên HP-150 chính là khi ngón tay người chạm vào màn hình, các tia hồng ngoại sẽ bị chặn lại, từ đó máy tính có thể hiểu được vị trí của điểm tiếp xúc. Tuy nhiên, đây là một sự bất tiện lớn đối với những người có kích thước ngón tay quá lớn hoặc quá nhỏ.

Một năm sau đó, vào năm 1984, cong nghệ cảm ứng đa chạm tiếp tục đạt được một bước tiến lớn với sự ra đời của màn hình cảm ứng đa chạm trong suốt đầu tiên do nhà nghiên cứu Bob Boie tại Phòng thí nghiệm Bell Labs phát triển. Đây là thế hệ màn hình sử dụng mạng lưới các cảm biến điện dung phủ lên bề mặt của màn hình CRT thông thường nhằm phát hiện vị trí tiếp xúc. Theo nhận xét của Bill Buxton, thiết kế trên cho phép người dùng có thể dùng tay để điều khiển các đối tượng ảo với mức độ phản hồi tuyệt vời.

Đây cũng bước ngoặt quan trọng trong sự phát triển của màn hình cảm ứng, mở đường cho sự ra đời của công nghệ cảm ứng trên smartphone hay tablet mà chúng ta sử dụng ngày nay.

Những năm 1990: Màn hình cảm ứng cho mọi người!
IBM_Simon.

Thiết bị Simon Personal Communicator của IBM: thiết bị di động màn hình cảm ứng điện trở kích thươc lớn đi kèm cùng bút stylus​

Vào năm 1993, IBM và BellSouth cùng nhau hợp tác và phát triển thành công Simon Personal Communicator (SPC) – một trong những chiếc điện thoại di động đầu tiên sử dụng công nghệ màn hình cảm ứng. SPC có thể hỗ trợ các tính năng như nhắn tin, ứng dụng mail, lịch, thời gian biểu, sổ danh bạ, máy tính và một ứng dụng hỗ trợ vẽ hình bằng bút cảm ứng. Dĩ nhiên, do sử dụng công nghệ cảm ứng điện trở nên SPC cũng đi kèm với một chiếc bút stylus nhằm thực hiện các thao tác điều hướng, chọn menu hay nhập dữ liệu.

Cũng trong năm 1993, Apple bắt đầu nhảy vào thị trường PDA với sự ra đời của chiếc Newton PDA phiên bản đầu tiên mang tên MessagePad 100. Sự kiện này góp phần thay đổi sâu sắc tầm nhìn của công nghệ màn hình lẫn nền công nghiệp thiết bị di động trong thời gian sau đó. Theo ghi nhận của tờ Times thì cũng chính John Sculley, CEO bấy giờ của Apple, là người đầu tiên đặt ra thuật ngữ PDA (trợ lý cá nhân kỹ thuật số) để chỉ dòng sản phẩm này.
404px-Apple_Newton-IMG_0454-cropped. Nguyên mẫu MessagePad 100 đầu tiên của Apple​
Tương tự như Simon của IBM, MessagePad 100 tích hợp máy tính điện tử, lịch, sổ địa chỉ và ứng dụng ghi chú. Người dùng sử dụng một cây bút để chọn và nhập văn bản lên màn hình cảm ứng điện trở. Đồng thời, Newton có khả năng nhận dạng chữ viết tay nên người dùng có thể ghi chú trực tiếp lên màn hình. Từ khi bắt đầu ra mắt, những tính năng hữu ích này đã gây sự chú ý của đa số người dùng, đặc biệt là đối với các đối tượng cần xử lý công việc một cách nhanh chóng và tiện lợi.

Tuy nhiên, sau một thời gian ra mắt, MessagePad 100 cũng bộc lộ nhiều khuyết điểm đáng kể. Nghiêm trọng nhất chính là chức năng nhận diện chữ viết tay hoạt động không được ổn định và thiếu chính xác. Từ đó, doanh số bán MessagePad 100 cũng không khả quan như Apple mong muốn. Và sau đó 6 năm, Apple tiếp tục tung ra MessagePad 200 với hy vọng cải thiện chức năng lẫn công nghệ nhằm vực dậy lĩnh vực PDA vốn vẫn còn quá non trẻ.

Palmpilot5000_eu. Chiếc PDA Palm Pilot đầu tiên​

3 năm sau đó, Palm Computing chính thức giới thiệu chiếc PDA đầu tiên của hãng mang tên Pilot. Tương tự như Simon hay MessagePad, Pilot của Palm cũng hỗ trợ các tính năng nhắn tin, ghi chú, lịch,… thông dụng và dĩ nhiên, công nghệ màn hình vẫn là cảm ứng điện trở đồng hành với chiếc bút stylus huyền thoại. Tuy nhiên do “sinh sau đẻ muộn”, nên Palm đã phần nào nhận biết được các khuyết điểm trên những chiếc PDA tiền nhiệm. Đặc biệt là tính năng nhận diện chữ viết tay Graffiti cho phép nhập văn bản, số và các ký tự khác đã nhận được những phản hồi hết sức tích cực từ phía người dùng.

Cho tới thời điểm bấy giờ, thiết bị dạng PDA với 3 đại diện nói trên vẫn có điểm chung là sử dụng công nghệ cảm ứng điện trở và được bán kèm với chiếc bút stylus để thực hiện thao tác điều khiển chính xác trên màn hình. Một số người dùng vẫn đòi hỏi khả năng chạm trực tiếp bằng tay nhưng vẫn đảm bảo độ chính xác tuy nhiên, công nghệ vẫn chưa thể đáp ứng được nhu cầu này.
iGesture-Pad.

Thiết bị IGesture Pad của FingerWorks​

Gần cuối những năm 1990, Wayne Westerman, một cử nhân tại Đại học Delaware đã quyết định chọn công nghệ màn hình cảm ứng làm đề cho tài luận văn tiến sĩ của mình. Đề tài mang tên: “Hand Tracking, Finger Identification, and Chordic Manipulation on a Multi-Touch Surface” (Nhận diện bàn tay, xác nhận ngón tay và thao tác Chordic trên bề mặt cảm ứng đa chạm) đã mô tả chi tiết cơ chế hoạt động của màn hình cảm ứng đa chạm – thế hệ màn hình mà ngày nay chúng ta biết đến với cái tên “Màn hình cảm ứng điện dung”. Đây được xem như một bước chuyển mình quan trong của công nghệ cảm ứng, mở ra cánh cửa cho sự phát triển các thiết bị cảm ứng trong thời gian sau đó.

Ngay sau đó, Westerman và giáo sư hướng dẫn của ông là John Elias đã cùng nhau thành lập nên công ty FingerWorks. Hãng bắt đầu sản xuất ra các thiết bị với công nghệ màn hình cảm ứng đa chạm mà đại diện là bàn phím cảm ứng TouchStream. Sản phẩm này đã nhận được sự đón nhận khá tích cực của người dùng, đặc biệt là có thể hỗ trợ những người khuyết tật hoặc bị chấn thương có thể thao tác máy tính dễ dàng hơn.

Cùng năm, hãng tiếp tục cho ra đời thiết bị mang tên IGesture Pad cho phép người dùng có thể điều khiển 1 tay bằng cách chạm và thao tác trên màn hình. Cho đến năm 2005, FingerWorks chính thức được Apple mua lại và toàn bộ những công nghệ cảm ứng góp phần cho sự ra đời của huyền thoại iPhone sau này.

Những năm 2000: Bùng nổ!

Với sự hình thành và phát triển của hàng loạt công nghệ màn hình cảm ứng tích lũy được trong nhiều thập kỷ trước, những năm 2000 là khoảng thời gian mà công nghệ màn hình cảm ứng đạt có sự phát triển mạnh mẽ nhất. Có lẽ giới hạn bài viết này không đủ để chúng ta kể hết và chi tiết về tất cả những thiết bị có màn hình cảm ứng.

Tuy nhiên, mục này sẽ điểm qua một số dấu ấn quan trọng của công nghệ màn hình cảm ứng trong khoảng thời gian này. Một số nhà phân tích còn cho rằng, những năm 2000 chính là thời kỳ mà màn hình cảm ứng trở thành công cụ chủ yếu phục vụ các cuộc hợp tác nhằm thiết kế và phát triển sản phẩm.

Năm 2001: Alias|Wavefront và General Motors hợp tác phát triển PortfoliaWall
siggraph112. PortfolioWall đang đuợc sử dụng tại một nhóm thiết kế xe hơi​
Đầu những năm 2000, nhiều công ty bắt đầu nhận thấy được tiềm năng hứa hẹn của công nghệ màn hình cảm ứng và dành nhiều nguồn lực vào việc phát triển các thiết bị có màn hình cảm ứng. Một trong số các sản phẩm đó chính là PortfolioWall – một chiếc màn hình cảm ứng cỡ lớn do liên minh công nghệ giữa Alias|Wavefront và General Motors nhằm hỗ trợ công việc thiết kế hoạt hình 3D tại các studio.

Được phát triển từ năm 1999 và chính thức giới thiệu tại triển lãm đồ họa máy tính SIGGRAPH vào năm 2001. Đây là thành quả từ quá trình phát triển gần 2 năm do nhóm nghiên cứu dẫn đầu bởi Buxton, vị giáo sư đến từ Đại học Toronto đã bắt đầu nghiên cứu công nghệ màn hình cảm ứng từ thập niên 80. Hiện nay, ông vẫn đang tiếp tục thực hiện các dự án nghiên cứu tại phòng thí nghiệm của tập đoàn Microsoft.

​Trong một báo cáo, Buxton cho biết rằng: “Chúng tôi đã phá vỡ suy nghĩ truyền thống về những bức tường và cung cấp thêm công cụ giao tiếp hiệu quả tại nơi làm việc hoặc kinh doanh. Giao diện người dùng của PortfolioWall hoàn toàn có thể cho phép người dùng trực tiếp với thế giới số. Giờ đây, hình ảnh đã trở thành một phần tất yếu trong công việc thường nhật của mỗi người.”

Thật vậy, PortfolioWall sở hữu thiết kế khá đơn giản, dễ dùng dựa trên các thao tác điều khiển bằng cử chỉ tự nhiên của người dùng. Thiết bị cho phép người dùng duyệt và tùy chỉnh hình ảnh, trình chiếu ảnh động và các đoạn video. Phiên bản tiếp theo của PortfolioWall còn hỗ trợ thêm khả năng phác họa hình ảnh và ghi chú trực tiếp bằng các đoạn văn bản. Bên cạnh đó, người dùng cũng có thể chạy các ứng dụng bên thứ 3, công cụ duyệt vật thể 3D thiết kế bằng Maya.
sport_car_3.

PortfolioWall cho phép nhà thiết kế có thể thao tác trên những mô hình đồ họa 3D với kích thước thật​

Với các tính năng trên, PortfolioWall nhanh chóng trở thành thiết bị được sử dụng rộng rãi bởi nhiều nhà thiết kế. Tuy nhiên, cái giá của nó cũng không “dễ chịu” tý nào: 38.000 đô la cho phiên bản đầy đủ. Sự ra đời của PortfolioWall đã dần hình thành nên lối tư duy mới trong công tác thiết kế đồ họa bằng việc số hóa các mô hình thiết kế thay vì phải sử dụng đất sét hay bảng vẽ trên giấy như truyền thống.

Ngoài ra, PortfolioWall còn hỗ trợ nhiều người dùng có thể tham gia thiết kế, trình chiếu trực tuyến thông qua hệ thống máy chủ. Tính năng này giúp nhiều thành viên trong một nhóm dự án có thể làm việc từ xa mà không cần phải trực tiếp đến studio như trước đó. PortfolioWall chính thức bị khai tử vào năm 2008 nhưng thiết bị trên đã trở thành một ví dụ điển hình về công nghệ màn hình cảm ứng và giao diện người dùng vào đầu thế kỷ 21.

Năm 2002: Cảm biến điện dung tương hỗ trên SmartSkin của Sony

​Vào năm 2002, Sony giới thiệu SmartSkin – một thiết bị có bề mặt phẳng, có khả năng nhận diện nhiều tư thế của bàn tay và điểm chạm tại cùng 1 thời điểm. Công nghệ này hoạt động bằng cách tính toán khoảng cách giữa bàn tay và bề mặt thông qua hệ thống cảm biến điện dung và các ăng ten hình lưới. Khác với công nghệ nhận diện cử chỉ bằng camera, hệ thống cảm biến điện dung được kích hợp ngay trên bề mặt màn hình của SmartSkin cho phép thiết bị có thể hoạt động trong những môi trường ánh sáng kém
sony-smartskin. ảnh mô tả hoạt động của SmartSkin​

Tham vọng ban đầu của Sony là có thể dùng SmartSkin để sử dụng mỗi ngày trên các bức tường, bảng viết trong trường học,… Tuy không đạt được mức độ phổ biến mong muốn, nhưng SmartSkin đã có đóng góp không nhỏ cho sự phát triển của màn hình cảm ứng điện dung và đa điểm sau này. Jun Rekimoto, nhà nghiên cứu tại Phòng thí nghiệm tương tác thuộc Sony cho biết rằng công nghệ trên SmartSkin hỗ trợ nhiều người dùng tương tác bằng nhiều bàn tay cùng một lúc. 2 phiên bản của SmartSkin chính là minh chứng rõ ràng nhất cho khả năng tuyệt vời này.

2002-2004: Sự thất bại

Có thể nói, công nghệ cảm ứng có mối quan hệ hết sức mật thiết với những chiếc màn hình thủy tinh. Đây là mối liên hệ dường như không thể phá vỡ được. Tuy nhiên, cách tiếp cận của hãng DSI Datotech đến từ Canada đã đi ngược hoàn toàn với lối suy nghĩ trên. Năm 2002, hãng ra mắt thiết bị nhận diện cử chỉ mang tên HandGear. Đây là một chiếc touchpad đa điểm tương tự như iGesture Pad với khả năng nhận diện các cử chỉ điều khiển, cho phép người dùng sử dụng như một thiết bị nhập liệu đầu vào.
handgear. Ảnh chụp thiết bị nhập liệu đầu vào hỗ trợ đa chạm HandGear​
Cựu giám đốc Marketing của hãng, Tim Heaney đã phát biểu rằng: “Chúng tôi muốn tạo HandGear với triết lý một sản phẩm thật sự dễ dùng. Do đó, công nghệ được thiết kế nhằm nhận diện bàn tay và các ngón tay theo cách hết sức tự nhiên và trực quan bất kể người dùng thuận tay trái hay tay phải. Nếu sau một thời gian ngắn sử dụng, người dùng sẽ sử dụng cả bàn tay để làm việc chứ không còn là những ngón tay nữa.”

Bên cạnh đó, HandGear cũng hỗ trợ người dùng “bắt” các vật thể 3 chiều theo thời gian thực, thao tác và tùy biến vật thể trong quá trình thiết kế. Đồng thời, hãng cũng dự định sẽ hợp tác với hãng AutoDesk nhằm phát triển các hàm API cho HandGear. Tuy nhiên, do gặp các vấn đề tài chính nên công ty đã không thể chính thức thương mại hóa sản phẩm và DSI cũng đóng cửa không lâu sau đó.

​2 năm sau, vào năm 2004, Andrew D. Wilson, một nhà nghiên cứu tại Microsoft Research đã phát triển thành công hệ thống nhận diện cử chỉ bằng màng hình cảm ứng và màn hình hiển thị 3D. Hệ thống mang tên TouchLight sử dụng một màn hình chiếu ở phía sau để bè một tấm plastic bằng acrylic thành bề có khả năng tương tác. Màn hình TouchLight có thể nhận diện được thao tác chạm của nhiều ngón tay và bàn tay của nhiều người dùng. Cộng thêm khả năng 3D, TouchLight còn có thể được sử dụng như một chiếc máy nhân bản lâm thời, hiển thị toàn bộ hình ảnh 3 chiều của người dùng.

TouchLight gần như đã trở thành một cuộc cách mạng công nghệ. Tuy nhiên, cuối cùng sản phẩm vẫn không được cấp phép sản xuất hàng loạt do giá thành quá cao so với một thiết bị tiêu dùng. Dù vậy, TouchLight đã đánh dấu sự kiện Microsoft cũng sớm đặt chân vào mảnh đất đầy màu mỡ của công nghệ màn hình đa chạm.

Năm 2006: Công nghệ FTIR
still1. Chiếc màn hình cảm ứng đa chạm của Jeff Han​
Vào năm 2006, nhà khoa học Jeff Han đến từ New York đã ra mắt giới công nghệ thế hệ màn hình máy tính mới với giao diện hoàn toàn trực quan và điều khiển bằng công nghệ cảm ứng trong khuôn khổ sự kiện TED Conference tổ chức tại Monterey, California. Trong bài giới thiệu, Han đã dùng ngón tay của mình để di chuyển và chỉnh sửa các bức ảnh trên một màn hình cảm ứng điện dung. Tất cả các thao tác kéo thả, co dãn, thu phóng hình ảnh đều được thực hiện hết sức tự nhiên và trực quan. Chiếc màn hình của Han còn có độ phân giải cao và có thể chế tạo ở kích thước lớn nhưng vẫn đảm bảo chi phí hợp lý.

Điểm mấu chốt chính là Han đã phát hiện ra rằng việc cảm ứng đa điểm hoàn toàn có thể được thực hiện bằng kỹ thuật frustrated total internal reflection (ngăn chặn sự phản chiếu ánh sáng cục bộ xảy ra bên trong màn hình, công nghệ FTIR). Trên thực tế, đây là một kỹ thuật được các nhà sinh trắc học thường sử dụng để ghi lại dấu vân tay. Công nghệ FTIR hoạt động bằng cách chiếu ánh sáng qua một mẩu acrylic hoặc thủy tinh pkexi (thủy tinh nhựa dẻo). Ánh sáng (thường là tia hồng ngoại) sẽ bị phản xạ lên xuống giữa các tấm acrylic.
FTIR.

Nguyen lý cơ bản của công nghệ FTIR do Jeff Han phát hiện​

Khi ngón tay chạm xuống bề mặt, tia sáng sẽ bị tán xạ xung quanh rìa của khu vực tiếp xúc. Đó cũng là lý do vì sao công nghệ trên có tên gọi là “frustrated” (chặn). Khi đó, các hình ảnh tạo thành trông giống như các đốm màu trắng và sẽ được nhận diện bằng camera hồng ngoại. Sau đó, thông tin điểm chạm sẽ được máy tính phân tích, đánh dấu vị trí và gán cho nó một tọa độ. Cuối cùng, phần mềm sẽ phân tích tọa độ và thực hiện các lệnh điều khiển cụ thể.

Jeff Han đang trình diễn công nghệ cảm ứng đa điểm của ông trong khuôn khổ sự kiện TED Conference tổ chức tại Monterey, California năm 2006​

Tuy sở hữu công nghệ cảm ứng đầy hứa hẹn, nhưng do nhiều vấn đề đã khiến Han không thể chính thức thương mại hóa sản phẩm màn hình cảm ứng công nghệ FTIR. Cuối cùng, Han đã bán công ty của mình cho gã khổng lồ Microsoft với hy vọng rằng công nghệ của ông sẽ sớm nhận được các sự đầu tư đúng mức nhằm đến tay người tiêu dùng.

Năm 2007: Steve Jobs và chiếc smartphone logo quả táo

mọi suy nghĩ của người dùng về màn hình cảm ứng đã hoàn toàn thay đổi với sự ra đời của chiếc iPhone vào năm 2007. Đó là một chiếc màn hình với khả năng cảm ứng cực kỳ chính xác, giá thành chế tạo không cao, hoạt động mượt mà và đặc biệt là có thể cảm ứng đa chạm. Màn hình cảm ứng trên iPhone bao gồm một ma trận các cảm biến điện dung liên kết với nhau và bố trí khắp bề mặt màn hình. Do đó, hệ thống có thể cảm nhận được vị trí chính xác của điểm chạm thông qua cảm biến độc lập thay vì phải đo điện dung của toàn màn hình như hồi năm 1966.

Công nghệ trên chẳng những cho phép iPhone có khả năng cảm ứng đa điểm mà còn hỗ trợ nhiều thao tác điều khiển phức tạp như “pinch to zoom” và dĩ nhiên là “slide to unlock” huyền thoại. Đồng thời, ma trận cảm biến dày đặt bên dưới màn hình giúp thiết bị có thể hỗ trợ các thao tác đòi hỏi độ chính xác cao như gõ bàn phím,…
steve-jobs-holding-iphone.

Steve Jobs và iPhone 2G​

Bên cạnh đó, bước tiến lớn nhất mà iPhone đạt được chính là hệ thống phần mềm với thiết kế dựa trên chủ nghĩa duy vật. Theo đó, các đối tượng ảo trên iOS đều thuận theo thao tác vật lý tự nhiên của con người. Ví dụ như người dùng có thể vuốt, chạm, kéo,… các vật thể ảo với đầy đủ thuộc tính như trọng lượng, độ ma sát,… Tất cả những điều đó tạo cho người dùng cảm giác đang tương tác với một vật thể trong thế giới thực hơn là biểu tượng trong màn hình di động. Đây cũng chính là ý tưởng quan trọng nhất chi phối toàn bộ thiết kế giao diện tương tác giữa người dùng với máy tính trên các thiết bị sau này.

Nối gót ra đời của iPhone, hàng loạt các thiết bị di động hỗ trợ màn hình cảm ứng điện dung tiếp tục ra đời. Đồng thời, hệ điều hành được viết dành riêng cho các thiết bị di động cũng được phát triển và dần hoàn thiện như Android hay Windows Phone,… Cho đến hiện nay, màn hình cảm ứng điện dung đã hiện hữu trên hầu hết các thiết bị di động hiện nay, từ Smartphone đến Tablet và thậm chí là các Laptop có hỗ trợ màn hình cảm ứng. Đồng thời, không chỉ Apple mà nhiều hãng công nghệ khác đều trang bị công nghệ cảm ứng điện dung cho các sản phẩm của mình như Samsung, LG, HTC,…

Năm 2007-2008: Microsoft Surface ra đời
surface.

​Trước khi chiếc máy tính bảng 10 inch mang tên “Surface” ra mắt thì ý tưởng thiết kế đã nhen nhóm bởi một nhà khoa học tại Redmon với hy vọng tìm cách chế tạo chiếc bàn cảm ứng cho phép các sinh viên của ông có thể tương tác trực tiếp trên bề mặt của nó. Nhiều năm sau đó, công việc nghiên cứu đã được âm thầm thực hiện trong vòng bí mật với các hợp đồng không thể tiết lộ. Và sau 85 nguyên mẫu ra đời với nhiều cải tiến, cuối cùng thì chiếc Surface 1.0 đã chính thức được Bill Gates giới thiệu vào năm 2007.

Đây là một chiếc máy tính bảng kích thước trung bình với một màn hình rộng, phẳng bên trên. Hình ảnh của Surface được chiếu lên từ bên dưới bề mặt và thao tác chạm của người dùng sẽ được nhận diện thông qua hệ thống camera tích hợp bên dưới bề mặt màn hình. Khi các ngón tay tiếp xúc với vật thể trên màn hình, phần mềm sẽ ghi nhận lại điểm chạm và kích hoạt các hành động tương ứng.

Bill Gates tiết lộ thông tin về Surface thế hệ đầu tiên​

Chiếc Surface đầu tiên được giới thiệu tại sự kiện All Things D vào năm 2007. Cùng với iPad của Apple Galaxy Tab của Samsung,… Surface là một minh chứng cụ thể cho sự phát triển sâu rộng của công nghệ màn hình cảm ứng trong thế giới công nghệ hiện nay. Tiếp theo, tại triển lãm CES 2008, Microsoft tiếp tục giới thiệu phiên bản Surface 30 inch nhằm hướng tới các đối tượng khách hàng doanh nghiệp, dự án hoặc trong môi trường kinh doanh,…

Công nghệ màn hình tiếp theo?
IOS-8-beta-public.

​Những màn hình cảm ứng đa điểm thế hệ mới luôn được tiếp tục hoàn thiện về cả độ phân giải lẫn số lượng điểm chạm cùng một lúc ngày càng tăng. Song song với điều đó, thiết kế giao diện đa chạm cũng ngày càng được hoàn thiện với hàng loạt các phiên bản phần mềm ra đời hướng tới việc trực quan và thân thiện với người dùng hơn. Xu hướng chủ đạo sẽ là là phẳng hóa mọi thứ như trên iOS 7, iOS 8 hoặc Android L với ngôn ngữ thiết kế material.

Mục tiêu cuối cùng trong giao diện cảm ứng sẽ là ngày càng thu hẹp khoảng cách giữa thế giới ảo và thế giới kỹ thuật số. Đó không chỉ là những chiếc màn hình khô cứng mà là sự tương tác mang tính 2 chiều giữa con người và thiết bị. Người dùng sẽ dùng tay và các thao tác tự nhiên để tương tác với thiết bị. Ngược lại, thiết bị cũng phản hồi một cách chính xác và hợp lý trở lại người dùng.

Video dùng thử LeafMotion, thiết bị điều khiển máy tính bằng cử chỉ​

Cùng với sự phát triển của công nghệ, tương tác giữa con người và máy tính hứa hẹn được nâng lên một cấp độ mới: không chạm vào màn hình. Điển hình như thiết bị LeafMotion mà Tinh Tế đã từng giới thiệu với các bạn. Đó là một hệ thống camera 3 chiều bắt được các chuyển động của bàn tay người dùng và chuyển thành thao tác trong máy tính. Hay cụ thể hơn là công nghệ nhận diện chuyển động 3D trên Kinect của Microsoft. Người dùng hoàn toàn có thể thực hiện các động tác hoàn toàn tự nhiên và các chuyển động sẽ được số hóa vô cùng chính xác.

Một ví dụ khác có thể phần nào giúp chúng ta hình dung về công nghệ tương tác trong tương lai chính là thiết bị thực tế ảo Oculus Rift. Khi đó, con người sẽ thực sự bước vào thế giới ảo và tương tác với trong đó như thế giới thật. Đây hứa hẹn sẽ là mô hình tương tác của con người với máy tính trong tương lai không xa. Tuy nhiên, hiện tại thì công nghệ tương tác 3 chiều chưa thực sự hoàn hảo do phần lớn chỉ là tương tác 1 chiều từ người dùng đến vật thể ảo.

​Dĩ nhiên là nếu muốn tương tác này trở nên thực hơn và tương hỗ nhiều hơn thì cần phải có phản hồi chiều ngược lại, túc là từ vật thể ảo đến con người. Ví dụ đơn giản như nếu bạn thực hiện cầm nắm một vật thể ảo thì phải có cách giúp ta cảm thấy được sức nặng của nó và thậm chí là cảm giác như lên da chúng ta. Lúc đó thì tương tác mới trở nên “thật” hơn và sống động hơn,… Một vấn đề khác là kiểu tương tác trên có thật sự an toàn? Có khả năng rò rỉ thông tin hay không?

Kết
touch.

​Tất cả các vấn đề trên đều đang được nghiên cứu và tìm ra giải pháp thích hợp. Đồng thời, sự phù hợp giữa phần cứng và phần mềm cũng là vấn đề cần được quan tâm nghiên cứu trong tương lai. Đã 7 năm từ khi Steve Jobs giới thiệu chiếc iPhone thế hệ đầu tiên, rõ ràng ở góc độ nào đó, chúng ta có quyền mơ về một cuộc cách mạng tiếp theo sẽ diễn ra trong tương lai không xa. Ban đầu, mình cũng đã khá bất ngờ khi biết rằng công nghệ cảm ứng đầu tiên được sử dụng lại là điện dung. Tất cả người dùng chúng ta, dù iOS hay Android, BlackBerry hay Windows Phone đều phải thầm cám ơn E. A. Johnson khi cầm trên tay chiếc smartphone hoặc tablet của mình. Cuối cùng, cám ơn các bạn đã theo dõi bài viết. Chúc vui vẻ.