วันอังคารที่ 7 กรกฎาคม พ.ศ. 2552

ความผิดพลาดของคอมพิวเตอร์อาจเป็นต้นเหตุให้เครื่องบินตก

จากการสอบสวนหาสาเหตุการตกของเครื่องบิน Air France เที่ยวบินที่ 447 ผู้เชี่ยวชาญคาดว่าสาเหตุอาจเกิดจากการทำงานที่ผิดพลาดของคอมพิวเตอร์และอุปกรณ์ต่าง ๆ ที่ต่อเนื่องกันเป็นลูกโซ่ ทั้งนี้เนื่องจากในปัจจุบันเครื่องบินเจ็ตขนาดใหญ่จะถูกควบคุมอัตโนมัติทั้งหมดด้วยระบบคอมพิวเตอร์ ซึ่งสิ่งนี้ก็ถูกตั้งคำถามต่อไปในประเด็นที่ว่า นักบินได้รับการฝึกฝนเพียงพอหรือไม่ ในการที่จะจัดการกับปัญหาในกรณีที่คอมพิวเตอร์ควบคุมการบินมีการทำงานที่ผิดพลาด

ที่มา The Wall Street Journal

วันศุกร์ที่ 17 ตุลาคม พ.ศ. 2551

ปริศนา Java 2



หลังจากเขียนภาคหนึ่งไว้ตั้งแต่สองสามเดือนก่อน คราวนี้ก็มาต่อภาคสองสักทีนะครับ สำหรับภาคนี้ คำถามก็ยังเหมือนเดิมครับ คือผลลัพธ์จากโปรแกรม Java นี้คืออะไร




import java.net.*;
import java.util.*;
public class URLSet {
 private static final String[] URL_NAMES = {
  "http://www.google.com", 
  "http://www.ajsarun.blogspot.com",
  "http://www.ajsarun.bloggang.com",
  "http://ajsarun.blogspot.com",
  "http://kisarun.multiply.com",
  "http://www.google.com"
 };
public static void main(String[] args) throws MalformedURLException {
  Set favorites = new HashSet();
  for(String urlName: URL_NAMES) {
   favorites.add(new URL(urlName));
  }
  System.out.println(favorites.size());
 }
}


  1. 4

  2. 5

  3. 6

  4. ขึ้นอยู่กับการรันแต่ละครั้ง




เราลองมาวิเคราะห์โปรแกรมนี้กันดูนะครับ จะเห็นว่าเราประกาศอะเรย์ของ String ชื่อว่า URL_NAMES โดยสมาชิกแต่ละตัวของอะเรย์ก็คือ URL ของเว็บไซต์ต่าง ๆ แต่จะเห็นว่ามี http://www.google.com ซ้ำกันอยู่ 2 ที่ จากนั้นที่เมท็อด main เราสร้างออบเจ็กของคลาส HashSet (ซึ่งจัดเป็นข้อมูลแบบเซ็ต) ใน for loop ก็มีการสร้างออบเจ็กต์ของ class URL โดยใช้สมาชิกแต่ละตัวจากอะเรย์ URI_NAMES และเก็บอ็อบเจกต์ของคลาส URL แต่ละตัวลงในเซ็ต พวกเราคงทราบนะครับว่าข้อมูลในเซ็ตจะไม่ซ้ำกัน แต่เรามีwww.google.com ซ้ำกันอยู่ 2 ตัวดังนั้น ดังนั้นข้อมูลในเซ็ตก็ควรจะมี 5 ตัว เมื่อเราสั่งพิมพ์ขนาดของเซ็ตออกมาในบรรทัดสุดท้าย ผลลัพธ์ก็ควรจะเป็น 5 ใช่ไหมครับ คำตอบก็ควรจะเป็นข้อ B

แต่ไม่ใช่ครับ คำตอบคือข้อ D. ประหลาดใจไหมครับ คือถ้าคุณต่ออินเทอร์เน็ตอยู่ผลลัพธ์จะเป็นข้อ A. คือ 4 แต่ถ้าไม่ผลลัพธ์จะเป็น 5 ทำไมจึงเป็นเช่นนั้น เรามาดูกันครับ ความลับอยู่ที่เมท็อด equals ของคลาส URL ครับ วิธีการเปรียบเทียบว่า URL จะเท่ากันหรือไม่ดูดังนี้ครับ กล่าวคือถ้าเราต่ออินเทอร์เน็ตอยู่ มันจะแปล URL ไปเป็นหมายเลข IP ถ้าหมายเลข IP เท่ากันก็ถือว่าเป็น URL ตัวเดียวกัน แต่ถ้าเราไม่ต่ออินเทอร์เน็ต มันก็จะเอาค่าสตริงของ URL มาเปรียบเทียบ โดยไม่คำนึงถึงตัวอักษรตัวเล็กหรือตัวใหญ่


มาดูกรณีต่ออินเทอร์เน็ตอยู่ จะพบว่าในสตริงมี http://www.google.com สองครั้ง ซึ่งก็ต้องได้ หมายเลข IP เดียวกันแน่นอน คราวนี้มาพิจารณาดู URL สองตัวนี้ครับ http://www.ajsarun.blogspot.com กับ http://ajsarun.blogspot.com สองตัวนี้จะให้ผลลัพธ์เป็นหมายเลข IP เดียวกัน นั่นก็หมายความว่าจะมีหมายเลข IP ที่ไม่ซ้ำกันอยู่ทั้งหมด 4 ตัวเท่านั้น ดังนั้นผลลัพธ์จึงเป็น 4


สำหรับกรณีที่ไม่ต่ออินเทอร์เน็ต มันก็จะเปรียบเทียบค่าสตริง URL ว่ามี http://www.google.com อยู่ 2 ตัว ซึ่งซ้ำกัน ที่เหลือไม่ซ้ำดังนั้นผลลัพธ์จึงเป็น 5

เป็นยังไงครับรู้สึกอยากด่าหรืออยากเลิกใช้ Java ไปเลยไหมครับ คราวนี้ทำไมจึงเป็นเช่นนี้ พิธีกรเขาให้เหตุผลว่าในสมัยก่อนที่มีการสร้างคลาสนี้ยังไม่มีแนวคิดของการที่มีชื่อ URL ที่ต่างกัน แต่อ้างถึงหมายเลข IP เดียวกัน


วิธีการแก้ไขถ้าต้องการให้ได้ผลลัพธ์ที่เหมือนเดิมเสมอไม่ว่าจะต่ออินเทอร์เน็ตหรือไม่ ให้ใช้คลาสที่ชื่อ URI แทนครับ ดังนั้นโปรแกรมในตอนต้นจะต้องเปลี่ยนเป็นดังนี้ครับ





import java.net.*;
import java.util.*;
public class URISet {
 private static final String[] URI_NAMES = {
  "http://www.google.com", 
  "http://www.ajsarun.blogspot.com",
  "http://www.ajsarun.bloggang.com",
  "http://ajsarun.blogspot.com",
  "http://kisarun.multiply.com",
  "http://www.google.com"
 };
 public static void main(String[] args) {
  Set favorites = new HashSet();
  for(String uriName: URI_NAMES) {
   favorites.add(URI.create(uriName));
  }
  System.out.println(favorites.size());
 }
}




ซึ่งคลาส URI นี้จะพิจารณาโดยใช้สตริงเท่านั้น คือไม่มีการไปแปลงเป็นหมายเลข IP ใด ๆ ดังนั้นผลลัพธ์จะเป็น 5 เสมอ แต่ก็ยังเป็นการเปรียบเทียบแบบไม่สนใจตัวอักษรตัวเล็กหรือตัวใหญ่เช่นเดิมนะครับคือ http://www.google.com กับ http://www.GOOGLE.COM ก็ถือว่าเท่ากัน

สิ่งที่พิธีกรเขาสรุปจากปริศนานี้ก็คือ เขาบอกว่าเราไม่ควรใช้ URL กับ class SET หรือ class MAP เพราะว่ามันออกแบบมาไม่ดี ให้ใช้ URI แทน ซึ่งตรงนี้ผมว่าถ้าใครไม่ได้เขียนโปรแกรมที่เกี่ยวข้องกับเรื่องพวกนี้ก็อาจดูจะไกลตัวไปนะครับ

แต่สิ่งที่เขาเน้นและผมก็คิดว่าสำคัญก็คือ เวลาเราเขียนโปรแกรม Java เมท็อดตัวหนึ่งที่เรามักจะ override ก็คือเมท็อด equals ก็ขอให้คิดไว้เสมอนะครับว่า เมท็อด equals นี้ไม่ควรจะให้ผลลัพธ์ที่เปลี่ยนไปตามสภาพแวดล้อมของการทำงาน


ผู้เขียนยินดีที่จะให้นำบทความไปเผยแพร่ต่อไปได้ถ้าไม่ได้นำไปใช้เพื่อการค้า แต่ขอให้บอกที่มาว่ามาจากผู้เขียนด้วย

วันเสาร์ที่ 26 กรกฎาคม พ.ศ. 2551

การพัฒนาโปรแกรมแบบเรียงลำดับกำลังจะตาย!

ที่มา http://searchdatacenter.techtarget.com/news/article/0,289142,sid80_gci1319113,00.html#

"การคำนวณแบบเรียงลำดับกำลังจะสูญพันธ์ และอนาคตก็คือการคำนวณแบบขนาน" วันนี้ผมขอเริ่มบทความด้วยคำกล่าวของ Dave PAtterson ซึ่งเป็นหัวหน้าห้องปฎิบัติการการคำนวณแบบขนานที่มหาวิทยาลัยแคลิฟอร์เนียที่เบิร์กเลย์ ซึ่งได้กล่าวไว้ในงานสัมมนาทางวิชาการที่ชื่อว่า Usenix Conference อ่านแล้วรู้สึกยังไงครับ ตกใจ แปลกใจ ไม่เห็นด้วย เฉย ๆ เห็นด้วย แน่นอนอยู่แล้ว ...

เอาละครับ เราลองมาดูรายละเอียดกันดูดีไหมครับว่าทำไมเขาจึงกล่าวเช่นนี้ ซึ่งจริง ๆ ความคิดของเขาก็มาจากการที่การพัฒนาของตัวหน่วยประมวลผลในปัจจุบันนี้ซึ่งเป็นแบบหลายแกน (multi cores) กันแล้วนั่นเอง ซึ่งแน่นอนครับว่าถ้าเราต้องการจะใช้ประโยชน์จากจุดนี้เราก็ต้องพัฒนาโปรแกรมในแบบขนาน อย่างไรก็ตามศาตราจารย์ Andrew S. Tanenbaum (รู้จักไหมครับ เจ้าพ่อด้านระบบปฏิบัติการคนหนึ่งที่พัฒนา Minix ขึ้นมาเพื่อใช้ในการสอนระบบปฏิบัติการ เป็นแรงบันดาลใจให้ Linus ไปพัฒนา Linux) ได้กล่าวติงว่าการพัฒนาโปรแกรมแบบเรียงลำดับนั้นก็ยากอยู่แล้ว การพัฒนาโปรแกรมแบบขนานยิ่งยากไปกว่านั้นอีก เขาเกรงว่าถ้าเราเขียนโปรแกรมให้ทำงานไปพร้อม ๆ กันบนแกนเหล่านี้ โปรแกรมที่พัฒนาขึ้นจะเลวร้ายลงไปอีก ซึ่ง Patterson ก็เห็นด้วยในเรื่องนี้ว่าเรายังขาดบุคลากรทางด้านนี้อยู่จริง ๆ

ไม่ทราบว่ามีความเห็นกันอย่างไรบ้างครับ อย่างนี้เราต้องเลิกเรียนวิชาเขียนโปรแกรมแบบธรรมดาไปเลย แล้วมาเขียนโปรแกรมแบบขนานกันดีไหม ไม่หรอกนะครับ เพราะการพัฒนาแบบเรียงลำดับมันเป็นพื้นฐานที่ต้องเข้าใจ เหมือนกับต้องนับหนึ่งก่อน และขั้นตอนวิธีต่าง ๆ ก็มักจะพัฒนาขึ้นมาแบบเรียงลำดับก่อน แล้วจึงพัฒนาเป็นแบบขนาน ยิ่งไปกว่านั้นก็ไม่ใช่ว่าโปรแกรมทุกโปรแกรมจะต้องทำงานแบบขนาน แต่ผมเป็นห่วงเรื่องของบุคลากรเช่นกันครับ ยิ่งเห็นนักศึกษาบางคนอยู่จนปีสามหรือปีสี่แล้วยังเขียนโปรแกรมกันไม่คล่อง ขั้นตอนวิธีโครงสร้างข้อมูลพื้นฐานก็ยังไม่ค่อยจะเข้าใจกัน ดังนั้นต้องฝากพวกเราโดยเฉพาะที่กำลังเรียนอยู่นี่จะต้องตั้งใจเรียนการพัฒนาโปรแกรมให้เข้าใจอย่างลึกซึ้ง จากนั้นถ้าเห็นแนวโน้มนี้แล้วก็น่าจะเลือกวิชาเช่นขั้นตอนวิธีแบบขนานไว้เป็นวิชาเลือก และคิดว่าในอนาคตก็คงต้องมีการปรับปรุงหลักสูตร โดยให้มีวิชาที่เกี่ยวกับการพัฒนาโปรแกรมแบบขนานเป็นวิชาบังคับ และมีวิชาเลือกให้มากขึ้น

วันอาทิตย์ที่ 20 กรกฎาคม พ.ศ. 2551

ปริศนา Java 1

ต้องขอเกริ่นก่อนนะครับว่าต่อไปบล็อกนี้ผมจะเขียนเรื่องที่หนักไปทางวิทยาการคอมพิวเตอร์มากขึ้น เพราะเท่าที่ดูผู้อ่่านของผมในบล็อกนี้ก็คือศิษย์ปัจจุบันหรือศิษย์เก่า ส่วนถ้าใครยังติดใจเรื่องเล่าข่าวไอทีต่าง ๆ ก็ขอเชิญที่บล็อกของผมที่ bloggang นะครับ

หลังจากเอาวีดีโอขึ้นไปให้ดูกันจากบทความที่แล้ว ก็มีเสียงบ่นว่าวีดีโอยาวจัง ไม่มีเวลาดู ผมก็เลยคิดว่าจะหยิบยกปริศนาภาษา Java จากวีดีโอมาคุยให้ฟังแล้วกันนะครับ เริ่มจากปริศนาแรกเลยนะครับ

import java.util.*;
public class ShortSet {
public static void main(String[] args) {
Set s = new HashSet();
for (short i = 0; i < 100; i++) {
s.add(i);
s.remove(i-1);
}
System.out.println(s.size());
}
}

คำถามคือผลลัพธ์จากโปรแกรมนี้คืออะไร
a. 1
b. 100
c. Throw Exception
d. None of the above

ลองมาไล่โปรแกรมดูนะครับ ถ้าไล่โปรแกรมไปตามปกติจะเห็นว่าเป็นการนำเอาตัวเลข 0 ถึง 99 ใส่ลงใน Set แต่ในการใส่ในแต่ละครั้งจะมีการเอาตัวที่อยู่ก่อนหน้าออก ถ้าลองไล่ดูที่ i = 0, จะได้ set {0} และเมื่อพยายามจะ เอา (0-1 = -1 ) ออกจาก set จะพบว่าไม่มี -1 ดังนั้นจึงไม่มีการเอาอะไรออก ในรอบแรกนี้ set จะมีค่า {0} ในรอบที่ 2 i = 1 จะได้ set คือ {0,1} และเมื่อเอา (1-1 = 0) ออกจะได้ว่า set คือ {1} ดังนั้นถ้าทำอย่างนี้ไปเรื่อย ๆ ในรอบสุดท้ายเราจะได้ set คือ {99} ดังนั้นผลลัพธ์ของโปรแกรมที่สั่งพิมพ์คือขนาดของ Set ก็จะต้องเป็น 1 แต่ถ้าลอง run โปรแกรมดูจะได้ผลลัพธ์คือ 100 ซึ่งคือข้อ b.ครับ คำถามคือทำไม...
คำตอบคือตอนแรกควรจะมามาเข้าใจ interface Set กันก่อน ซึ่งมีหน้าตาดังนี้ครับ
Interface Set {
boolean add(E e);
boolean remove (Object o);
...
}

ให้สังเกตุนะครับว่าสำหรับ add จะรับพารามิเตอร์เป็นประเภทที่ระบุไว้ นั่นหมายความว่าเราไม่สามารถใส่ข้อมูลประเภทอื่น ๆ ที่ไม่ได้ระบุไว้ตั้งแต่ตอนสร้าง set ลงใน set ได้ แต่ remove พารามิเตอร์้เป็น Object ซึ่งหมายถึงจะเป็นประเภทข้อมูลอะไรก็ได้ ซึ่งก็ดูประหลาดนะครับ แต่เหตุผลหนึ่งของการทำอย่างนี้ก็คือในเรื่องของ backward compatability และเขาก็บอกว่าได้ลองคิดถึงการที่จะออกแบบให้ใช้ remove(E e) แล้วแต่ปรากฏว่ามันใช้ไม่ได้ในหลายกรณี เขายกตัวอย่างว่าสมมติว่าถ้าเราต้องการจะหา intersection ระหว่าง Set ของ Number กับ Set ของ Long ซึ่งในกรณีนี้เราจะต้องสามารถดึง object ของ Long ออกมาจาก Numberได้
เอาละครับคราวนี้ก็มาดูว่าอะไรทำให้ผลลัพธ์ไม่ได้ตามที่ต้องการ จากบรรทัด s.remove(i-1) จะเห็นว่าผลลัพธ์ของ i-1 จะเป็น int และจากคุณสมบัติ Autoboxing ก็จะทำให้ได้ผลลัพธ์เป็น object ของ Integer ให้สังเกตุว่าข้อมูลใน Set ที่เราใส่เข้าไปเป็น Short แต่เวลาจะเอาออกเราหา object ของ Integer ซึ่ง object ของ Integer และ Object ของ Short ไม่สามารถเทียบกันได้ดังนั้นการ remove แต่ละครั้ง จึงไม่มีการเอาอะไรออกจาก set
ถ้าจะให้โปรแกรมนี้ทำงานตามที่ต้องการ พอจะตอบได้ไหมครับว่าต้องแก้ตรงไหน ....

ใช่แล้วครับ ต้องแก้บรรทัด s.remove(i-1) เป็น s.remove((short) (i-1)) ซึ่งจะทำให้ได้ผลลัพธ์เป็น Short
สิ่งที่ได้จากปริศนา Java นี้ก็คือผลลัพธ์ของการคำนวณเกี่ยวกับจำนวนเต็มจะได้เป็น int หรือ long ดังนั้นให้หลีกเลี่ยงการใช้ short ในโปรแกรมนะครับ เขายกตัวอย่างว่ากรณีเดียวที่น่าจะใช้ short ก็คือการใช้ array ของ short เท่านั้น

หมายเหตุ : บทความนี้ผู้เขียนยินดีที่จะให้นำไปเผยแพร่ต่อได้ แต่ขอให้อ้างอิงที่มาว่ามาจากผู้เขียนด้วย

วันเสาร์ที่ 12 กรกฎาคม พ.ศ. 2551

มาทดสอบความรู้ Java กันดีกว่า

สำหรับวันนี้ผมจะขอนำเสนอวีด๊โอที่เกี่ยวกับการเขียนโปรแกรมภาษา Java มาให้ทดสอบความรู้กันนะครับ ผมเห็นว่าน่าสนใจดี ซึ่งผมว่าวีดีโอนี้ไม่เพียงแต่จะแสดงคุณลักษณะของภาษา Java เท่านั้น แต่ยังแสดงให้เห็นการออกแบบบางอย่างที่ไม่ดีของ
คลาสไลบรารีของภาษาอีกด้วย ซึ่งก็น่าจะเป็นตัวอย่างหรือเป็นข้อคิดสำหรับนักพัฒนาระบบบ้านเรานะครับ



อ้อไม่ต้องกังวลถ้าตอบผิดนะครับ ผมก็ตอบผิดครับ :(