Pages

Monday 28 June 2010

Thời của Kindle: đọc sách cũng là kết nối

Tác giả: STEVEN JOHNSON

Kindle của Amazon, Nook của Barnes&Noble, những chiếc máy đọc sách như vậy đang dần tạo nên bước ngoặt trong văn hóa đọc: mở ra một không gian "ảo" để độc giả kết nối, chia sẻ và khám phá.

Máy đọc sách sẽ "pha loãng" sự tập trung?
"Mục tiêu của sách báo là chống lại sự cô đơn", đó là nhận định của nhà văn Mỹ tài năng David Foster Wallace trong phần mở đầu cuốn sách mới xuất bản của tác giả David Lipsky: "Although of Course You End Up Becoming Yourself" (tạm dịch: Mặc dù cuối cùng bạn chắc chắn vẫn là chính mình).
Nếu đọc cuốn sách này trên sách điện tử Kindle của Amazon, bạn sẽ thấy nhận định đó của Wallace đã được đặc biệt nhấn mạnh bằng cách gạch chân. Đó không phải là vì Wallace hay Lipsky cảm thấy cần làm như vậy. Lý do thực sự là bởi có rất nhiều độc giả đã đánh dấu đoạn này trên sách điện tử Kindle của mình, khiến nó trở thành đoạn văn "hot" nhất trong cả cuốn sách.
Amazon đặt tên cho chức năng tự động gạch chân các đoạn văn được độc giả yêu thích là "các đoạn đánh dấu phổ biến". Thoạt nhìn chức năng này có vẻ "vô thưởng vô phạt", nhưng trên thực tế lại báo hiệu những cơ hội lớn phía trước.
Với "các đoạn đánh dấu phổ biến", ngay cả khi chúng ta tắt mạng xã hội Twitter hay TV và ngồi đọc một cuốn sách hay thì sẽ có rất nhiều độc giả khác cũng đang giở từng trang sách để cùng chúng ta tìm ra những lời hay ý đẹp. Không lâu nữa, chúng ta sẽ có thể gặp những người bạn độc giả này để cùng chia sẻ câu chuyện. Đọc sách chỉ để chống lại sự cô đơn ư? David Foster Wallace mới nhìn thấy một mặt của vấn đề.
Tuy nhiên, không phải ai cũng nhìn nhận những chức năng mới như vậy là sự tiến bộ. Nicholas Carr, trong cuốn sách "The Shallows" (tạm dịch: Những người nông cạn) của mình cho rằng các hành động đọc lướt, đoán ý và làm nhiều việc cùng một lúc khi đọc trên màn hình điện tử đang đi ngược lại với mục tiêu đọc sâu và kĩ đã tồn tại trong nhiều thế kỉ của văn hóa đọc.
Máy đọc sách giúp chúng ta đa năng ngay cả khi đọc sách, nhưng liệu có làm pha loãng sự tập trung? Ảnh minh họa
Carr cho rằng đọc sách trong khi đang tiến hành các hoạt động khác sẽ gây ra sự lãng phí lớn, ảnh hưởng xấu đến khả năng tập trung. Quan điểm này của ông đã nhận được sự đồng tình từ nhiều nghiên cứu khoa học.
Một nghiên cứu mới công bố đã cho thấy hiệu quả làm việc của những người làm rất nhiều việc cùng một lúc sẽ giảm từ 10 - 20% so với những người làm ít việc hơn.
Các nghiên cứu này chắc chắn đã chứng minh được một điều rằng không ai thật sự tin là mình có thể tập trung được khi phải chuyển qua chuyển lại giữa các hoạt động khác nhau. Tuy nhiên do bỏ qua những lợi ích thu được khi làm nhiều thứ cùng một lúc, những nghiên cứu này lại trở thành một tiêu chí văn hóa vô nghĩa.
Kết nối trong không gian ảo
Hãy xem, nhờ có email, Twitter và blog, chúng ta có thể thường xuyên trao đổi thông tin với hàng trăm người mỗi ngày: sắp xếp lịch họp, tán gẫu, biên tập cuốn sách mới, hay đọc các bình luận về thế giới công nghệ... Nếu chúng ta bị giới hạn bởi các dịch vụ điện thoại, bưu chính và các cuộc gặp gỡ trực tiếp thì chúng ta có thể trao đổi được bao nhiêu thông tin? Có lẽ chỉ là một phần rất nhỏ so với lượng thông tin đang được trao đổi hiện tại của chúng ta.
Chúng ta không nghi ngờ gì về việc mình có hơi mất tập trung khi thực hiện các giao tiếp này, tuy nhiên thành thật mà nói, phần lớn những việc chúng ta làm trong ngày đều không đòi hỏi sự tập trung cao độ.
Trong cuốn sách của mình, Carr không chỉ tỏ ra lo lắng cho mức độ tập trung của độc giả. Ông còn cảnh báo: "tư duy văn học, tuyến tính" vốn là trái tim của nghệ thuật, khoa học và xã hội thì nay có nguy cơ trở thành "tư duy lạc hậu" với những hậu quả khôn lường đối với nền văn hóa. Dù có nhiều lý do khác nhau, nhưng ở điểm này, có lẽ Carr đã lo lắng hơi thái quá.
Hệ quả đầu tiên của việc suy nghĩ "nông cạn" đáng lẽ đã phải xuất hiện ngay từ khi thế giới công nghệ ra đời bởi khi đó, con người dành phần lớn thời gian của mình trong không gian siêu kết nối. Tuy nhiên, trên thực tế, trong 15 năm qua, các bình luận truyền thông đã phát triển theo hướng ngày càng trở nên thật sự tinh tế và sắc sảo. Chẳng hạn, ngay từ khi mới xuất hiện, bài viết của Carr trên báo The Atlantic và nhận định lạc quan hơn của Clay Shirky trong cuốn "Cognitive Surplus" (tạm dịch: Dư thừa nhận thức) đã trở thành hai chủ đề được bàn luận nhiều nhất trên các trang web.
Một khi sự quan tâm từ giới hàn lâm và phê bình chuyên nghiệp xuất hiện thì các công cụ tri thức vốn dùng để đánh giá ngành truyền thông sẽ càng dễ tiếp cận hơn với số đông dân chúng. Hiện nay số người đăng lên mạng những phản hồi sâu sắc cho bài tiểu luận của Carr chắc chắn đủ để "đánh bẹp" số người viết bình luận về cuốn sách "Understanding Media" (tạm dịch: Hiểu về truyền thông) của Marshall McLuhan xuất bản năm 1964.
Vấn đề không ổn trong mô hình của Carr là sự tôn sùng vô điều kiện dành cho việc đọc kĩ, suy nghĩ sâu. Thực tế là rất nhiều ý tưởng lớn giúp xã hội phát triển trong các thế kỉ vừa qua lại xuất phát từ không gian kết nối rộng mở, trong sự giao thoa của các quan điểm và xúc cảm, sự hội tụ của các phép so sánh cũng như các lĩnh vực chuyên môn khác nhau.
Đọc sách đang dần trở thành một hoạt động kết nối, chia sẻ, khám phá ý tưởng. Ảnh minh họa
Không phải ngẫu nhiên mà phần lớn các phát minh khoa học công nghệ quan trọng trong thiên niên kỷ vừa qua đều bắt nguồn từ những trung tâm đô thị náo nhiệt. Bản thân các trang giấy đã khuyến khích sự đa dạng trong kết nối bằng cách lưu giữ, chia sẻ và truyền bá hiệu quả các ý tưởng. Ví dụ như ở thời kỳ Khai sáng con người đã bắt đầu tập trung nhiều hơn vào việc trao đổi ý tưởng thay vì đọc một mình.
Suy nghĩ trong yên tĩnh tạo điều kiện thuận lợi cho sự chia sẻ các ý tưởng quan trọng. Tuy nhiên cũng không thể phủ nhận rằng các ý tưởng thú vị cũng xuất hiện trên mạng trực tuyến.
Đúng là màn hình điện tử đang khiến chúng ta trở nên kém tập trung hơn. Đúng là sự hỗ trợ đáng kể từ sách điện tử Kindle và iPad cũng không thể thay đổi xu hướng lười đọc các tác phẩm và bài báo dài so với 50 năm về trước. Đây chắc chắn là những bất lợi. Nhưng lợi ích là gì? Chúng ta sẽ đọc nhiều văn bản hơn, viết nhiều hơn so với những gì chúng ta đã làm trong thời hoàng kim của vô tuyến truyền hình.
Không những thế, tốc độ đón nhận ý tưởng và khám phá các khía cạnh mới trong một vấn đề của chúng ta cũng sẽ tăng lên đáng kể. Chúng ta kém tập trung hơn, nhưng lại kết nối nhiều hơn. Và tất cả chúng ta đều vui vẻ chấp nhận sự đánh đổi đó.
Linh Giang dịch. Bài báo đăng trên New York Times

Sunday 20 June 2010

Immigration-law developments

Immigration-law developments

Here are last week's developments related to Arizona's new immigration law, known as Senate Bill 1070. The law makes it a state crime to be in the country illegally. It states that an officer engaged in a lawful stop, detention or arrest shall, when practicable, ask about a person's legal status when reasonable suspicion exists that the person is in the U.S. illegally.

Cities that have approved boycotts of Arizona:

• Sacramento. The City Council approved the boycott Tuesday on a 6-1 vote. Mayor Kevin Johnson, a former Phoenix Suns star, and five other council members voted to approve the boycott.

• Burlington, Vt.

Public bodies that announced Arizona boycotts:

• Santa Monica (Calif.) College District Board of Trustees.

Other actions for and against:

• A trip to the annual Airborne Law Enforcement Association conference, scheduled for Tucson in July, was canceled for the four Los Angeles Police Department officers who were scheduled to attend.

• Republican leaders in the Indiana Senate want the city of Bloomington to think twice about its decision to boycott Arizona businesses. A letter dated Thursday from Sen. Mike Delph, R-Carmel, and signed by 23 other Republican senators asks Bloomington officials to "take a step back" from their plan to avoid doing business with Arizona companies.

For a complete list of Arizona boycotts or moves in support of SB 1070, go to money.azcentral.com.

Friday 18 June 2010

How Do I Downgrade My BlackBerry Firmware?

To downgrade your firmware means to install an older operating system in your device. You might do this because you don't like the updates that were added to the latest operating system. For example, many Windows users preferred to use Windows XP instead of Windows Vista because they don't like the changes that came with the newer software. Although BlackBerry doesn't recommend that you use outdated BlackBerry firmware, they do provide a way to downgrade your operating system through the BlackBerry Desktop Manager.


Instructions

  1. Step 1
    Download the BlackBerry firmware onto your computer that you want to install into your Blackbery phone

  2. Step 2
    Start the BlackBerry Desktop Manager on your computer. Connect your BlackBerry phone to your computer with the USB cable that came with the phone's purchase.

  3. Step 3
    Open the Application Loader program in the BlackBerry Desktop Manager main menu. Click "Start" under the Update Software section. Highlight the BlackBerry firmware you downloaded in Step 1. Click "Next" to confirm.

  4. Step 4
    Click "Finish" to start the installation process. Installation can take up an hour, depending on your handset. Disconnect your BlackBerry phone when you see the confirmation message stating that the BlackBerry firmware installation is complete.


Perl programs

This page contains some information about Perl programming. It is really not organized in any special manner. My intention was to collect some stuff that I occasionally find useful, and give access to it. Browse through the material if you like, and if you find anything useful anything interesting, or you think that something is missing send me a note and I might get around to doing something about this page.

I have recently added a Perl Cookbook with recipes for solving some problems you might run into. The recipes solves problems for which I haven't found a solution in the Perl Cookbook by Tom and Nathan. The contents of this page is:
  1. One-Liners
  2. Perl 5 Modules
  3. Programs both Perl 4 and Perl 5
    c++stat - diffsolve - e-mail - lcomplexity - mail-form - match - pgrep - rename - sum-garbage - sum-process - uniqpath - wordcount - mh2ns - scheduling.tgz - pack
  4. Examples
  5. XSUB packages

Shell Script Programming

This is a document that covers some issues regarding shell script programming. Note that this page is still under construction. The intension is that is should be possible to use it as a WWW text for "advanced" shell programming, but right now I am just collecting stuff.

Note! I use Bourne shell or derivatives thereof, like BASH. Therefore the scripts contained herein is written for Bourne shell (usually found under /bin/sh), unless said otherwise.
Also not that this is work in progress. Hence some of the descriptions might be bad, some might be confusing and yet some may be missing. If that is the case, please send me a note about it.
This document is structured as follows.
  1. Introduction
  2. Giving commands to the shell
  3. One-liners
  4. Tips & Tricks
  5. Exercises
  6. Examples of scripts
  7. Complete Scripts

Wednesday 16 June 2010

GIẢI QUYẾT 4 NỖI SỢ KHI THAY ĐỔI CÔNG VIỆC

Nhiều người cảm thấy bị mắc cạn trên con đường sự nghiệp của mình. Một công việc thật nhàm chán, không có cơ hội phát huy tài năng, một môi trường làm việc ngột ngạt… Thế nhưng họ rất ngại thay công đổi việc. Họ ngại rằng biết đâu đấy mình lại “tránh vỏ dưa gặp vỏ dừa” và nhiều nỗi sợ khác nữa…
Phương Trang là một ví dụ điển hình. Cô hiện làm việc với một tập đoàn đa quốc gia gần 4 năm trời, nhưng công việc của cô vẫn đều đều trôi qua, và cô vẫn “yên vị” ở vị trí hiện tại dù làm việc rất tốt. Nhiều khi cô cảm thấy ngán với công việc này vì ngày 8 tiếng cô vẫn làm công việc đó, nhưng cơ hội phát triển và thăng chức chưa bao giờ đến với cô. Khi được hỏi vì sao cô không tìm một công việc mới tốt hơn, Trang trả lời “Ngại tìm việc mới lắm. Đâu biết được môi trường mới có phù hợp với mình không…” Đó là 1 trong 4 nỗi sợ chính đã ngăn cản nhiều người tìm kiếm công việc yêu thích của mình.
Nỗi sợ thứ nhất - "Đâu biết được môi trường mới có phù hợp với mình không…" Thay đổi công việc có thể là một viễn cảnh không tươi sáng đối với nhiều người. Dù không hài lòng với công việc hiện tại (như trường hợp trên), nhiều người không dám “mạo hiểm” đi tìm cơ hội mới. Họ âm thầm chấp nhận công việc không mang đến cho họ cơ hội phát triển hay thăng tiến nhưng trong thâm tâm họ vẫn mong muốn một công việc khác tốt đẹp hơn. Đó là tâm lý “sợ thay đổi” khá phổ biến đối với nhiều người.
Thế nhưng, Thanh Hằng là một trường hợp ngược lại. Cô từng là một thư ký cho một công ty khá tiếng tăm. Thế nhưng quanh đi quẩn lại cô vẫn làm những công việc khá nhàm chán vì cô đã quá quen với tính chất “thường nhật” của chúng. Là một người năng động và yêu thích học hỏi thăng tiến, Hằng không ngại đi tìm công việc mới dù nhiều người quen khuyên cô “Mức lương này khá tốt với em rồi, sao lại thay đổi làm gì…”. Hằng vẫn kiên định với mục tiêu của mình và sau vài tháng cô đã tìm được công việc mang đến cho cô nhiều cơ hội học hỏi và thăng tiến.
Nỗi sợ thứ hai - "Tôi không có kinh nghiệm để làm công việc mình yêu thích" Nỗi sợ này xuất phát từ việc bạn ngại mình không có hoặc không thể làm công việc mới có tính chất khác biệt với công việc hiện tại của mình.
Bạn hãy nói chuyện với một số người đang làm công việc bạn mong muốn. Hãy hỏi họ xem những kỹ năng và kinh nghiệm nào là cần thiết để làm công việc mới mà bạn yêu thích. Nhờ đó bạn sẽ đánh giá được bản thân để biết được mình có đáp ứng được yêu cầu của công việc đó hay không và đâu là những điểm yếu cần khắc phục. Để nâng cao kỹ năng cần thiết cho công việc mới, hãy tích cực tìm hiểu và tham gia các hoạt động tình nguyện có liên quan đến công việc mới bạn muốn theo đuổi.
Đối với những người muốn chuyển sang một nghề nghiệp hoàn toàn mới, thường họ sẽ phải bắt đầu từ đầu, nghĩa là chấp nhận một công việc từ một vị trí thấp hơn và phát triển dần lên. Thay đổi nghề nghiệp cần một kế hoạch dài hạn, chứ không chỉ ngày một ngày hai. Nhiều người để theo đuổi một nghề hoàn toàn mới đã không ngại đầu tư thời gian và tiền bạc để học thêm một chuyên ngành mới hoặc theo học các khóa cao học (MBA là một ví dụ điển hình).
Nỗi sợ thứ ba - "Tôi không thể gánh vác nổi các khoản chi tiêu khi tìm việc" Đừng để bạn bị áp lực về tài chính. Bạn nên đặt ra một kế hoạch từ 6 đến 12 tháng để có thời gian chuẩn bị cho việc chuyển công tác. Kế hoạch này có thể là cắt giảm chi phí, gửi tiền tiết kiệm để bạn có thể chi tiêu trong thời gian đi tìm việc mới.
Hoặc bạn có thể làm hai việc song song. Bạn có thể làm những công việc mà mình yêu thích cho công ty khác vào những ngày cuối tuần. Bằng cách đó bạn vừa có thu nhập chắc chắn, lại vừa có thể rèn luyện cho mình những kỹ năng và kinh nghiệm cần thiết cho công việc mới.
Nỗi sợ thứ tư - "Bây giờ tôi đã quá già để thay đổi công việc” 
Nhiều người ngại đổi việc với cách giải thích trên trong khi họ chỉ hơn 30 tuổi là cùng! Tuổi tác không phải là vấn đề lớn bởi phụ nữ và nam giới ở độ tuổi 45-60, thậm chí trên 70 (cựu thủ tướng Singapore Lý Quang Diệu – người đã trên độ tuổi “thất thập cổ lai hy”, là một ví dụ điển hình) vẫn có thể đóng góp được nhiều kinh nghiệm quý giá cho công việc.
Đối mặt với nỗi sợ và quẳng gánh lo đi 
Một nghiên cứu cho thấy rằng những người yêu thích công việc của họ thường sống lâu hơn và đạt được kết quả làm việc tốt hơn hẳn. Điều đó hoàn toàn đúng. Vì vậy, đừng để nỗi sợ hãi là một yếu tố cản trở con đường sự nghiệp của bạn. Hãy bắt đầu với việc lập kế hoạch cho tương lai của bạn ngay ngày hôm nay.

BÍ QUYẾT CỦA NGƯỜI THÀNH CÔNG VÀ GIÀU CÓ

Bạn có biết những người có mục tiêu cụ thể cho cuộc đời mình là những người thành công và giàu có nhất? Cuộc khảo sát thực hiện tại trường đại học Yale ở Mỹ đã cho thấy sự khác biệt rất lớn giữa những người biết rõ mục tiêu của đời mình và những người không biết mình muốn gì trong cuộc sống.
Năm 1980, khi được hỏi về mục tiêu đặt ra cho cuộc đời, chỉ có 3% số sinh viên tham gia khảo sát viết ra mục tiêu và kế hoạch thực hiện cụ thể. 13% sinh viên có mục tiêu, nhưng không viết ra giấy. 84% còn lại hoàn toàn không biết (hoặc không có) mục tiêu hay kế hoạch nào.
15 năm sau, sự khác biệt giữa nhóm có mục tiêu rõ ràng cho cuộc đời mình và 2 nhóm còn lại thật sự gây bất ngờ. Số 13% sinh viên có mục tiêu nhưng không viết ra giấy có thu nhập cao gấp 2 lần những sinh viên không biết mình muốn gì trong đời. Điều gây ngạc nhiên lớn nhất nằm ở nhóm 3% sinh viên có mục tiêu và kế hoạch thực hiện chi tiết: họ có thu nhập cao gấp 10 lần tổng thu nhập của 97% sinh viên còn lại! (trích từ Never Eat Alone)
Đặt mục tiêu cho cuộc đời có quá khó khăn như nhiều người nghĩ không? Câu trả lời là “không” nếu bạn thực hiện các bước đơn giản sau:
1. Hãy trả lời câu hỏi “Tôi yêu thích gì?”
Tốt nghiệp ngành ngoại ngữ, Thi không biết được cô thật sự muốn làm việc ở lĩnh vực nào. Cô đã thử sức trong ngành kinh doanh và Marketing, nhưng kết quả không được như ý. Thi loay hoay đổi việc ở nhiều lĩnh vực khác nhau. Cuối cùng cô nhận ra rằng cô yêu tiếng cười và thế giới trẻ thơ biết bao. Hiện nay, Thi là một giáo viên giỏi và yêu nghề, làm việc tại một trường tiểu học quốc tế.
Vậy thì, trước tiên, bạn cần xác định rõ: Bạn thích làm việc gì nhất? Bạn đam mê điều gì từ thuở ấu thơ? Bạn có năng khiếu trong lĩnh vực nào và bạn muốn thử sức mình trong ngành nghề nào?
2. Hãy viết mục tiêu của bạn ra giấy
Nếu bạn không lên kế hoạch thực hiện mục tiêu của mình thì mục tiêu đó sẽ mãi là những ước mơ. Để mục tiêu của bạn trở thành sự thật, hãy lưu ý những điểm sau:
- Mục tiêu cần cụ thểchi tiết và rõ ràng. Bạn cần xác định các bước phải thực hiện và thời hạn hoàn thành.
- Mục tiêu cần thực tế và khả thi. Ví dụ nếu bạn muốn trở thành Giám đốc Tài chính, ít nhất bạn phải có trong tay bằng cử nhân Tài chính và một số kỹ năng khác để theo đuổi vị trí này. Nhiều người không bao giờ đạt được mục tiêu của mình vì mục tiêu họ đặt ra vượt quá xa khả năng của họ.
- Tuy nhiên, một mục tiêu quá bình thường sẽ chẳng có ý nghĩa. Vì vậy bạn nên đặt ra mục tiêu đầy hoài bão, thậm chí chấp nhận một số rủi ro nhất định.
3. Xác định cách thức phù hợp nhất để thực hiện mục tiêu
- Trước tiên, bạn cần thực hiện các mục tiêu ngắn hạn để tiến tới thực hiện các mục tiêu dài hạn hơn.
- Tìm hiểu xem ai có thể hỗ trợ bạn thực hiện các mục tiêu này nhanh chóng và hiệu quả nhất. Đó có thể là sếp của bạn, bạn thân hay một đồng nghiệp rất thành đạt ở công ty.
- Tận dụng các công cụ hỗ trợ giúp bạn đạt được mục tiêu dễ dàng hơn. Ví dụ nếu bạn muốn nâng cao khả năng nghe tiếng Anh thì bạn cần nghe và xem đài nước ngoài nhiều hơn.
4. Tìm “Ban Tư Vấn” cho bạn
“Ban Tư Vấn” có thể là người thân trong gia đình, bạn bè hay những người có nhiều kinh nghiệm. Hãy nhờ họ chỉ ra những điểm mạnh và điểm yếu của bạn. Từ đó, bạn sẽ biết được mình nên đầu tư thời gian và công sức cho mục tiêu nào.

Tuesday 15 June 2010

Thuốc chữa nhiệt miệng

Khi tiết trời khô hanh cũng là lúc nhiều người mắc bệnh nhiệt miệng, lở mồm. Tên khoa học là bệnh ap-tơ (aphtes) - một bệnh của niêm mạc miệng rất hay gặp (khoảng 20% dân số), nhưng căn nguyên bệnh vẫn chưa sáng tỏ.
Bệnh có nhiều thể khác nhau, trong đó thể đơn giản nhất cũng là thể gặp nhiều nhất từ trước đến nay là loại ap-tơ thông thường. Ap-tơ thường bắt đầu là một mụn nước nhỏ rất dễ giập vỡ để lại một vết trợt nông ở niêm mạc miệng, hình tròn hoặc bầu dục, đường kính từ 2-10mm, bờ rõ rệt, đáy màu vàng nhạt, xung quanh có một đường viền màu đỏ tươi, rất đau lúc nói hoặc khi ăn uống. Khu trú của ap-tơ thông thường là mặt trong má, ở rãnh môi - lợi, ở đầu lưỡi, ở bờ bên và nơi hãm lưỡi, đôi khi kèm theo viêm toàn bộ niêm mạc miệng. Bệnh thường không sốt, không gây sưng hạch vùng lân cận và thường tự khỏi trong vòng 10-15 ngày, không để lại sẹo, nhưng rất hay tái phát.
Người ta cũng nhận thấy có nhiều yếu tố ảnh hưởng đến sinh bệnh như: tình trạng stress, xúc động mạnh, rối loạn nội tiết như hành kinh, các rối loạn về tiêu hóa, các nhiễm khuẩn ở răng miệng, amidan, hoặc chấn thương ở niêm mạc miệng… có ảnh hưởng tới các đợt tái phát bệnh. Ngoài ra, trường hợp đặc biệt khác, một số bệnh viêm mạn tính đường tiêu hóa như bệnh loét chảy máu đại - trực tràng cũng có thể gây nên tái phát ap-tơ miệng.
Về điều trị, do chưa biết rõ căn nguyên, cơ chế gây bệnh nên chủ yếu điều trị triệu chứng, làm giảm độ tái phát của bệnh:
Điều trị tại chỗ:
- Declomycin: Là một alcaloid chiết xuất từ cây colchicum speciosum stev, thuốc mỡ 0,5%, ngày bôi 3-4 lần.
- Xylocain 5%: Thuốc gây tê tổng hợp tác dụng nhanh làm giảm đau nhưng chỉ có tác dụng thoáng qua, chấm tại chỗ lên ổ loét trước bữa ăn, 5-6 lần/ngày. Nếu đau quá thì dùng dung dịch dyclone.
- Kamistad-gel: Có tác dụng giảm viêm đau ở niêm mạc miệng và môi, bôi 3-4 lần/ngày.
- Borostyrol cream: Có tác dụng sát khuẩn, giảm đau, tạo sẹo, chấm tại chỗ 2 lần/ngày.
Điều trị toàn thân
- Levamisol: Thuốc có tác dụng tăng cường miễn dịch không đặc hiệu của cơ thể. Uống 150mg/ngày x 2-3 ngày, mỗi 15 ngày x 3-4 tháng.
- Colchicin: Có tác dụng điều trị những trường hợp tái phát nhiều lần nhờ khả năng làm giảm mật độ sự xuất hiện thường xuyên của vết viêm. Nếu hay tái phát và tiến triển dai dẳng thì có thể điều trị một đợt: 1-2mg/ngày x 5-7 ngày.
- Thalidomid: Chỉ dùng trong các trường hợp ap-tơ khổng lồ, do mức độ đau và độ nghiêm trọng hơn hẳn các thể khác. Thalidomid đặc biệt có hiệu quả với thể bệnh này, tác dụng của thuốc có thể thấy rõ sau 2-3 ngày dùng thuốc và bệnh sẽ khỏi sau 10-12 ngày điều trị. Nó còn có tác dụng tốt để điều trị những trường hợp tái phát nặng không đáp ứng với colchicin. Tuy nhiên, thalidomid có nhiều tác dụng phụ như gây quái thai, làm rối loạn hoạt động của các tế bào thần kinh ngoại biên, nên không được dùng cho phụ nữ có thai; nam giới trong thời gian điều trị bằng thalidomid và 3 tháng sau đó nếu quan hệ tình dục phải mang bao cao su ngừa thai.
Ngoài ra, trong mọi trường hợp, cần tăng cường vệ sinh răng miệng để tránh bội nhiễm, hạn chế diễn biến xấu. Uống corticoid chống viêm giảm đau và kháng sinh để chống nhiễm trùng; dùng vitamin C và các vitamin nhóm B liều cao tăng cường sức đề kháng. Với ap-tơ thông thường thể nhẹ có thể chỉ dùng thuốc bôi tại chỗ. Với thể tái phát nhiều lần liên tiếp, đau nhiều… thì cần đi khám bệnh, tùy theo từng trường hợp cụ thể (mức độ nặng nhẹ, tình trạng sức khỏe, giới, tuổi tác và tác dụng phụ của thuốc) thầy thuốc sẽ lựa chọn thuốc điều trị thích hợp.
BS. Vũ Hướng Văn

Ắc quy đỡ đần mùa cúp điện

Có thể đối phó với cúp điện bằng một hệ thống điện bình ắc quy không ồn ào, sử dụng nhiều lần và chi phí phù hợp

Ngoài bình ắc quy, cần có thêm máy đổi điện DC – AC. Thiết bị đổi điện DC – AC có chức năng đổi điện từ bình 
ắc quy DC 12V sang điện 220V AC, công suất từ 300 – 1.500W. Cũng có thể dùng thiết bị đổi điện sạc điện ngược lại vào bình ắc quy khi có điện để sử dụng khi điện cúp. Thời gian sử dụng của điện chuyển đổi từ bình ắc quy phụ thuộc vào các thiết bị điện trong nhà và công suất của bình. 
Như vậy, với một bình ắc quy 1.200W có thể sử dụng cùng lúc cho một bóng đèn huỳnh quang, quạt, máy tính, ti vi (toàn bộ khoảng 400W) trong khoảng 3 giờ liên tục. Dĩ nhiên, do giới hạn về công suất nên không thể sử dụng điện từ bình ắc quy cho những thiết bị điện có công suất lớn như máy lạnh, tủ lạnh, bàn ủi, máy bơm nước... 




Bình ắc quy: GS, Globe, Panasonic, JP (Pinaco – Đồng Nai), công suất từ 35 – 100AH. Giá từ780.000 – 1.600.000đ



Hệ thống 2 trong 1. Hàng của Đài Loan, vừa là thiết bị đổi điện DC – AC kết hợp theo bình ắc quy 20AH (công suất sử dụng 240W), trọng lượng nhẹ có thể mang theo du lịch, có đèn, có chức năng khởi động được xe máy. Giá 2.500.000đ



Hanshin 12V DC – AC. Hàng Việt Nam, công suất 300 – 500W, điện 12V, có mạch báo bảo vệ công suất vượt tổng. Giá từ 870.000 – 1.370.000đ



Genius Power G-12-030C. Hàng Đài Loan, công suất 300W, điện 12V. Giá 1.400.000đ


Trích dẫn:
Lưu ý: khi sử dụng
Lỗi thường gặp là người sử dụng đấu nhầm 2 điện cực (+) và (-) trên bình ắc quy. Lỗi này có thể gây hư hỏng thiết bị đổi điện. Khi muốn đấu nối điện bình đã chuyển đổi vào vị trí cầu dao tổng để dùng cho nhiều thiết bị điện trong nhà, người sử dụng nên nhờ kỹ thuật thiết kế một cầu dao đảo tại đây.

Monday 14 June 2010

Lessons in Test Automation



Summary:Elfriede Dustin has worked on many projects at various companies where automated testing tools were introduced to a test program lifecycle for the first time. In reviewing these projects, she has accumulated a list of "Automated Testing Lessons Learned," taken from actual experiences and test engineer feedback. In this article, she will share examples of this feedback, hoping that this information will help you avoid some typical false starts and roadblocks.



View Content Detail:

Lessons Learned

  •  Lessons in Test Automation.pdf
   (96 Kb)
 
I have worked on many projects at various companies where automated testing tools were introduced to a test program lifecycle for the first time. In reviewing these projects, I have accumulated a list of "Automated Testing Lessons Learned," taken from actual experiences and test engineer feedback. In this article I will share examples of this feedback compiled from real projects, hoping that this information will help you avoid some typical false starts and roadblocks.



Lessons Learned
The various tools used throughout the development lifecycle did not easily integrate.
A different tool was used for each phase of the lifecycle: a business modeling tool during the business analysis phase, a requirements management tool during the requirements phase, a design tool during the design phase, a test management tool during the testing phase, and so on. For metrics purposes—and to enforce consistency among the elements and traceability between phases—the goal was to have the output of one tool feed into the next tool used in the lifecycle. But because each of the tools used for the various phases was from a different vendor, they didn’t easily integrate. Trying to overcome those challenges and integrate the tools on this project was a complex effort. Much time was spent trying to move information from one tool set to another, using elaborate programming techniques, and resulting in extra work. The code generated to make those tools integrate was not reusable later, because of new upgrades to the various tools.
One possible corrective action would be for each project team to conduct a feasibility study to measure the need to purchase tools that are already integrated into a unified suite. A cost/benefit analysis should be conducted to determine whether the potential benefits of buying an integrated suite of tools would outweigh the costs.
Duplicate information was kept in multiple repositories.One of our project teams purchased a test management tool in addition to the already existing requirements management and automated testing tools. Duplicate information was kept in multiple repositories and was very difficult to maintain. In several instances, the implementation of more tools actually resulted in less productivity.
I have found that a requirements management tool can be used as a test management tool. There is no need to maintain test information in both tool databases. Maintenance can be improved by simply keeping most of the test progress and test status information in one tool.
The automated testing tool drove the testing effort.Often when a new tool is used for the first time on a testing program, more time is spent on automating test scripts than on actual testing. Test engineers may be eager to automate elaborate scripts, but may lose sight of the real goal, which is to test the application.
Keep in mind that automating test scripts is part of the testing effort, but does not replace the testing effort. Not everything can or should be automated. It is important to evaluate which tests lend themselves to automation. For example, only automate tests that are run many times, such as "smoke" (build verification) tests, regression tests, and mundane tests (tests that include many simple and repetitive steps). Also, automate tests that would be impossible (or prohibitively expensive) to perform manually, e.g., simulating 1,000 multi-user accesses.
Everyone on the testing staff was busy trying to automate scripts.On some projects we found that the division of labor—breaking up responsibilities so that all required testing activities are accomplished—had not been adequately defined. As a result, the entire team focused on the development of automated testing scripts.
It’s important to clearly define this division of duties. It is not necessary for the entire testing team to spend its time automating scripts; only a portion of the test engineers who have a development background should spend their time automating scripts. Manual test engineer expertise is still necessary to focus on all other test aspects. Again, let me stress that it is not feasible to automate everything.
Elaborate test scripts were developed, duplicating the development effort.I have witnessed test script development that resulted in an almost complete duplication of the development effort, through overuse of the testing tool’s programming language. In one of our projects, the application itself used a complex algorithm to calculate various interest rates and mortgage rates. The tester recreated these algorithms using the testing tool. Too much time was spent on automating scripts, without much additional value gained. One cumbersome script was developed using the tool’s programming language—but the same script could have been developed using the capture/playback feature of the tool and simply modifying the generated script in a fraction of time. The test team must be careful not to duplicate the development effort; this is a risk when developing elaborate test scripts. For each automated testing program it is important to conduct an automation analysis, and to determine the best approach to automation by estimating the highest return.Automated test script creation was cumbersome.It’s important that all teams involved understand that test script automation doesn’t happen automatically, no matter what the vendor claims. On one project, test engineers with manual test backgrounds were involved in creating the automated scripts. Basing their assumptions on the vendor claims of the tool’s ease of use, the test engineers complained that the creation of automated scripts took longer than expected, and that too many workaround solutions had to be found.
It’s important to understand that the tools are never as easy to use as the tool vendor claims. It is also beneficial to include one person on the testing staff who has programming knowledge and appropriate tool training, so that she can mentor the rest of the testing staff responsible for automation.
Training was too late in the process, so test engineers lacked tool knowledge.Sometimes tool training is initiated too late in the project for it to be useful for the test engineers using the tool. On one of our projects this resulted in tools not being used correctly. Often, for example, only the capture/playback portion of the testing tool was used, and scripts had to be repeatedly recreated, causing much frustration.
When introducing an automated tool to a new project, it’s important that tool training be incorporated early in the schedule as one of the important milestones. Since testing needs to be involved throughout the system development lifecycle, tool training should happen early in the cycle for it to be useful—and to ensure that tool issues can be brought up and resolved early. This involvement allows for testability and automation capabilities to be built into the system-under-test.
Mentors are also very important when first introducing tools to the testing program. Mentors must be very knowledgeable and should advise, but shouldn’t do the actual work.
The test tool was introduced to the testing program with two weeks left for system testing.I can recall one project in which system testing was behind schedule, and Management introduced a new testing tool in the hopes of speeding up the testing effort. Since we had a test automation expert on the team, we were able to leverage the use of the testing tool for such efforts as creating a smoke test script. The smoke test script automated the major functionality of the system; and before a new system test build was accepted, the smoke test script was played back to verify that previously working functionality had not been affected by new fixes.
We had taken a risk by introducing the tool so late in the process, but in this case we came out ahead: the script allowed for some timesaving. If no test automation expert had been on the test team, I would have suggested that the test team not accept the use of an automated testing tool this late in the lifecycle. The tool’s learning curve would not have allowed us to gain any benefits from incorporating it this late in the testing lifecycle.
Testers resisted the tool.The best automation tool in the world won’t help your test efforts if your team resists using it. In one case, the tool remained in the box—hardly any effort was invested in incorporating it into the process. The test engineers felt that their manual process worked fine, and they didn’t want to bother with the additional setup work involved in introducing this tool.
When first introducing a new tool to the testing program, mentors are very important, but you also need tool champions—advocates of the tool. These are team members who have experience with the tool, and who have first-hand experience in its successful implementation.
There were expectations of early payback.Often when a new tool is introduced to a project, the expectations for the return on investment are very high. Project members anticipate that the tool will immediately narrow down the testing scope, meaning reducing cost and schedule. In reality, chances are that initially the tool will actually increasethe testing scope.
It is therefore very important to manage expectations. An automated testing tool does not replace manual testing, nor does it replace the test engineer. Initially, the test effort will increase, but when automation is done correctly it will decrease on subsequent releases.
The tool had problems recognizing third-party controls (widgets).Another aspect of managing expectations is understanding the tool’s capabilities. Is it compatible with the system-under-test? On some projects the test engineers were surprised to find out that a specific tool could not be used for some parts of the application. During the tool evaluation period it is important to verify that third-party controls (widgets) used in the system-under-test are compatible with the automated testing tool’s capabilities.
If a testing tool is already in-house, but the system architecture has not been developed yet, the test engineer can give the developers a list of compatible third-party controls that are supported by the test tool vendor. If an incompatible third-party control is proposed, the test engineer should require a justification and explain the consequences.
A lack of test development guidelines was noted.One program had several test engineers, each using a different style for creating test scripts. Maintaining the scripts was a nightmare. Script readability and maintainability is greatly increased when test engineers can rely on development guidelines.The tool was intrusive, but the development staff wasn’t informed of this problem until late in the testing lifecycle.Some testing tools are intrusive—actual code has to be inserted into the code developed for the system-under-test in order for the automated tool to work correctly. In this case, the development staff wasn’t informed that the automated tool was intrusive; when they finally found out, they were very reluctant to incorporate the necessary changes into their code. Because of uncertainty about the tool’s intrusiveness, the first time that the system-under-test didn’t function as expected the intrusive tool was immediately blamed (even though there was no evidence that it had been the culprit).
In order to prevent this from happening, the test engineers need to involve the development staff when selecting an automated tool. Developers need to know well in advance that the tool requires code additions (if applicable—not all tools are intrusive). Developers can be assured that the tool will not cause any problems by offering them feedback from other companies who have experience using the tool, and by showing documented vendor claims to that effect.
Reports produced by the tool were useless.The test engineering staff on one project spent much time setting up elaborate customized reports using Crystal Report Writer, which was part of the automated testing tool. The reports were never used, since the data required for the report was never accumulated in the tool.
Before creating any elaborate reports, verify that the specific type of data is actually collected. Set up only reports specific to the data that will be generated. Produce reports as requested by Management or customers, and those reports required internally by the test program for measuring test progress and test status.
Tools were selected and purchased before a system engineering environment was defined.Some teams are eager to bring in automated tools. But there’s such a thing as too much eagerness: tools that are evaluated and purchased without having a system architecture in place can cause problems. When the decision for the architecture is being made, many compatibility issues can surface between the tools already purchased and the suggested architecture. I remember projects in which workaround solutions had to be found while trying to match the system-engineering environment to the requirements of the tools already purchased. A lot of vendor inquiries had to be made to determine whether the next release of the tools might be compatible with the system middle-layer that the project team wanted to choose.
To avoid these problems, it’s important that a system architecture be defined—and test tools selected—with all requirements (tool and architecture) in mind.
Various tool versions were in use.It’s possible for everyone to be using the same tool, and yet still not be able to talk to each other. On one project that had numerous tool licenses, we had various tool versions in use. That meant that scripts created in one version of the tool were not compatible in another version, causing significant compatibility problems and requiring many workaround solutions.
One way to prevent this from happening is to ensure that tool upgrades are centralized and managed by a Configuration Management department.
The new tool upgrade wasn’t compatible with the existing system engineering environment.Keep on top of product "improvements." On one project, a new tool version involved an upgrade that used the MSMail system for automatic defect notification to the MSExchange system. The vendor had omitted mentioning this upgrade detail. The project had invested a lot of money in a variety of test tool licenses and was caught by surprise by this new tool upgrade. The project’s company actually had plans to move to the Lotus Notes mailing system, but was still using MSMail. And using the Microsoft Exchange system, unfortunately, was not part of their plans at all. An elaborate workaround solution had to be found to allow for the tool’s compatibility with Lotus Notes.
Whenever a new tool upgrade is received, verify any major changes with the vendor. It’s often to your benefit to become a beta testing site for any new tool upgrades; this is a good way to incorporate your project’s issues or needs regarding any new upgrade.
It is also advisable to test a new tool upgrade in an isolated environment to verify its compatibility with the currently existing system engineering environment, before rolling out any new tool upgrade on a project.
The tool’s database didn’t allow for scalability.One project implemented a tool that used Access as its database. Once the test bed grew (test scripts, test requirements, etc.) and multiple test engineers tried to access the database, multi-user access problems surfaced. The database became corrupted several times and backups had to be restored.
To avoid this problem, pick a tool that allows for scalability using a robust database. Additionally, make sure to back up your testing tool database daily, if not twice a day.
Incorrect use of a test tool’s management functionality results in wasted time.In one specific test tool that allows for test management, test requirements can be entered into the tool in a hierarchical fashion. On one project, a person spent two weeks to enter test requirements in this hierarchy—ending up with 1,600 test requirements. When the test team was then ready to automate these test requirements, they realized that there was not enough time or resources to automate each of the 1,600 requirements. Much of the time spent entering these requirements was wasted, since only a fraction of the test requirements would eventually be automated. Planning and laying out milestones (what, when, and how something will be accomplished) still applies to automated testing.Solving ProblemsThese are just some of the various lessons I’ve learned, gathered from years working on various automated testing programs. But it’s not an exhaustive list. How should you deal with the problems you’ll encounter? In my book, Automated Software Testing, my co-authors and I discuss the following test improvement process:
The test team needs to adopt, as part of its culture, an ongoing iterative process focusing on lessons learned. Such a program encourages test engineers to raise corrective action proposals immediately, when such actions could potentially have a significant effect on test program performance. Test managers, meanwhile, need to promote such leadership behavior from each test engineer.
The metrics that are collected throughout the test lifecycle—and especially during the test execution phase—will help pinpoint problems that need to be addressed. Consequently, the test team should periodically "take a pulse" on the quality of the test effort. This will help improve test results, whenever necessary, by altering the specific ways that the test team performs its business. Not only should the test team concentrate on lessons learned for the test lifecycle, but it should also point out issues pertaining to the system development lifecycle.
Lessons you have learned, metrics evaluations, and any corresponding improvement activity or corrective actions need to be documented throughout the entire test process in an easily accessible central repository. A test team intranet site can prove very effective in maintaining such documentation. For example, lessons learned could be documented using a requirements management tool database, such as DOORS. Keeping an up-to-date database of important lessons learned provides all individuals on the project team with the ability to monitor the progress and status of issues throughout the project. A test team intranet can also make lessons learned available to all software professionals within the organization.
The test manager needs to ensure that records of lessons learned are viewed as improvement opportunities. The records, for example, should not list the names of the individuals involved in the particular activity. Each record should include at least one corrective action that suggests how the process or process output can be improved.
When lessons learned and metrics evaluation sessions take place at the end of a system development lifecycle, it is too late to take any corrective action for the current project. Nevertheless, lessons learned that are recorded at this stage can help to improve future test efforts; so it’s still worthwhile for the test team to document lessons learned, even at this late stage. The time and energy you invest in recording what you’ve learned will pay off on your next project. STQE

About the Author
Elfriede Dustin is a test manager at Computer Sciences Corporation and has recently published a book titled Automated Software Testing. She is also president of the Washington, DC area Rational Testing User Group. To contact her or to find out more about the book or the Rational Testing User Group, seehttp://www.autotestco.com.