วันพฤหัสบดีที่ 20 ตุลาคม พ.ศ. 2554

มาร่วมฝ่าวิกฤตน้ำท่วมไปด้วยกันครับ


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

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

วันนี้ก็ขอเสนอแนะไว้เท่านี้ครับ และเราจะฝ่าวิกฤตนี้ไปด้วยกันครับ ...

วันพุธที่ 5 ตุลาคม พ.ศ. 2554

ข้อดีของการที่ Apple ออก iPhone 4S ไม่ใช่ iPhone 5

วันนี้ขอเกาะกระแส iPhone กับเขาสักวัน ก็คงทราบกันไปแล้วนะครับว่า iPhone ตัวใหม่ของ Apple คือ iPhone 4S ไม่ใช่ iPhone 5 สรุปก็คือมีรูปทรงเดียวกับ iPhone 4 แต่คุณสมบัติการทำงานดีขึ้น ใครที่อยากทราบรายละเอียดก็เชิญที่บล็อกของ @ipattt ได้เลยครับ ซึ่งงานนี้ก็น่าจะสร้างความผิดหวังกับให้ผู้ที่รอคอย iPhone 5 บางส่วนไปไม่น้อยทีเดียว แต่ในวันนี้ผมจะมาลองสรุปมุมมองของผมเองต่อการเปลี่ยนแปลงเล็ก ๆ น้อย ๆ นี้ในส่วนที่จะเป็นข้อดีให้กับผู้บริโภคอย่างเราให้ฟังกันครับ
  1. ผู้ใช้ที่ต้องการซื้อ iPhone 4S จะซื้อได้ง่ายขึ้น ซึ่งปรากฏการณ์นี้ผมมมองว่าจะเหมือนตอนที่ Apple ออก iPhone 3GS ซึ่งซิ้อได้ง่ายมาก เมื่อเทียบกับ iPhone 3G ซึ่งต้องไปเข้าคิวต่อแถวซื้อกัน
  2.  ราคาของ iPhone 4 จะถูกลงอย่างแน่นอน ซึ่งสำหรับคนที่ไม่ได้ต้องการคุณสมบัติที่เพิ่มเติมขึ้นมาและตราบใดที่เจ้า iPhone 4 ยังสามารถอัพเกรดระบบปฏิบัติการต่อไปได้ ผมว่าทางเลือกนี้อาจเป็นทางเลือกที่เหมาะสม ในส่วนตัวผมคิดว่าถ้า Apple กล้าลดราคา iPhone 4 ลงมาเหลือประมาณหมื่นกลาง ๆ โดยตามข่าวรู้สึกว่าจะมี  iPhone 4 ซึ่งมีหน่วยความจำ 8 GB มันน่าจะเป็นตัวเลือกที่ดีที่สุดสำหรับมือถือราคาหมื่นกลางที่มีอยู่ตอนนี้เลยทีเดียว
  3.  อุปกรณ์เสริมต่าง ๆ สามารถใช้ร่วมกันได้
  4. คนที่เพิ่งซื้อ iPhone 4 ไป (โดยที่ไม่ได้ไปแหกคอกแหกกฏระเบียบที่ผู้จัดงานเขาจัดไว้) ก็ยังสามารถใช้งาน iPhone 4 ต่อไปได้ โดยไม่ต้องรู้สึกว่าซื้อมาปุ๊บก็ตกรุ่นปั๊บ
  5. คนที่ยังเก็บเงินได้ไม่ถึงก็มีเวลาเก็บเงินเพิ่มสำหรับ iPhone 5 
  6. เราก็มีเรื่องให้มานั่งเดานั่งลุ้นกันต่อไปว่า iPhone 5 จะเป็นอย่างไร 
สำหรับผมตอนนี้เท่าที่คิดออกก็มีแค่นี้ ใครที่เห็นข้อดีอื่น ๆ และอยากจะร่วมแสดงความเห็นก็เชิญได้ครับ

วันอังคารที่ 4 ตุลาคม พ.ศ. 2554

Use Case Diagram ไม่ใช่ Flowchart นะจะบอกให้

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

สำหรับเรื่องที่ต้องการจะเขียนวันนี้คือเรื่องที่ดูเหมือนจะง่าย ๆ ก็คือการเขียน Use Case Diagram จริง ๆ ผมตั้งใจจะเขียนมาหลายเดือนแล้ว เอหรือจะเกือบปีแล้วก็ไม่รู้ คือผมได้มีโอกาสไปบรรยายเรื่องการพัฒนาโปรแกรมให้กับหน่วยงานหน่วยหนึ่ง ก่อนที่จะบรรยายผมก็ลองให้โจทย์กับผู้อบรมลองเขียน Use Case Diagram ดู ปรากฏว่าผู้เข้าอบรมหลายคนเขียน Use Case Diagram เหมือนกับว่ามันเป็น Flowchart และวันนี้เองสด ๆ ร้อน ๆ กับนักศึกษาในที่ปรึกษาของตัวเองก็ดูเหมืือนว่าจะเข้าใจผิดไปในแนวทางนั้นเช่นกัน ดังนั้นก็เลยคิดว่าคงต้องเขียนบล็อกนี้ขึ้นมาเสียหน่อยเพื่อจะช่วยให้เรื่องนี้ชัดเจนขึ้น

ก่อนอื่นเรามาทบทวนกันก่อนว่า Use Case Diagram มีจุดประสงค์อะไร ซึ่งคิดว่าพวกเราคงตอบกันได้ว่ามันมีหน้าที่หลักในการแสดง Functional Requirement ของระบบ ตัว Use Case หนึ่ง Use Case เป็นตัวแทนของฟังก์ชันหลักฟังก์ชันหนึ่งของระบบ ดูก็ง่ายดีใช่ไหมครับ แล้วปัญหาใีนอยู่ตรงไหน ลองมาดูโจทย์ที่ผมได้ใช้ทดสอบผู้เข้ารับการอบรมกับผมกันก่อนครับ

  จงเขียน UML Diagram สำหรับระบบ ATM ที่่มีการทำงานคือฝากเงิน (Deposit) โอนเงิน (Transfer) และถอนเงิน (Withdraw) โดยจะต้องมีการตรวจสอบตัวตนของลูกค้าด้วย 

จากโจทย์ก็เป็นตัวอย่างพื้นฐานทั่วไป แต่มีผู้เข้ารับการอบรมหลายคนเขียน Use Case Diagram ในลักษณะนี้ครับ

Use Case Diagram แบบ Flowchart



ซึ่งผมก็ได้สอบถามว่าทำไมเขาถึงเขียนไดอะแกรม ในลักษณะนี้ คำตอบของเขาก็คือ ก็ทำตามโจทย์อาจารย์ ตรวจสอบสิทธิก่อนที่จะอนุญาตให้ทำธุรกรรมอย่างอื่น จะเห็นได้ชัดนะครับว่านี่คือความเข้าใจผิด ตัว Use Case Diagram ไม่ได้แสดงโฟลว์การทำงานว่าอะไรต้องทำก่อนอะไร อีกจุดหนึ่งที่ผมคิดว่าเป็นปัญหาของไดอะแกรมนี้ก็คือตัว Use Case ของเขาสองตัวคือ Enter Password และ Validate Password นั้นอยู่ในระดับที่ย่อยมากเกินไป

ถึงตรงนี้หลายคนก็อาจตั้งคำถามว่าแล้วเราควรจะเขียนอย่างไรดี ผมไม่ตอบดีไหมนี่ ทิ้งให้คิดเป็นการบ้าน มาเฉลยพรุ่งนี้ สวัสดีครับ ...... :)


ล้อเล่นน่ะครับ เฉลยเลยแล้วกันเดี๋ยวอึดอัดกันแย่ แนวทางหนึ่งที่จะเขียน Use Case Diagram สำหรับปัญหานี้ก็ตามนี้ครับ

Use Case Diagram สำหรับระบบ ATM อย่างง่าย 

จากไดอะแกรมนี้ผมได้รวมเอา Validate Password และ Enter Password เข้าด้วยกันเป็น Use Case ที่ชื่อว่า Authenticate และใช้ความสัมพันธ์  include เพื่อแสดงให้เห็นว่า Use Case ที่เหลือทั้งสามนั้นจะต้องมีการตรวจสอบตัวตนของผู้ถือบัตร ไดอะแกรมนี้แสดงความต้องการของระบบตรงตามที่โจทย์กำหนดได้อย่างชัดเจน และ Use Case Diagram ได้ทำหน้าที่หลักที่มันควรจะทำนั่นคือการแสดง Functional Requirement ของระบบ ไม่ได้แสดงโฟลว์การทำงาน อย่าลืมนะครับว่า Use Case Diagram เรามักจะสร้างขึ้นในช่วงวิเคราะห์ระบบ ซึ่งการวิเคราะห์ระบบควรจะตอบคำถามว่า "what" ซึ่งหมายความว่าระบบนี้ทำอะไรให้ได้เสียก่อน ไม่ใช่ไปตอบคำถามของคำว่า "how" ซึ่งหมายถึงว่ามันทำงานอย่างไร ถ้ามีแนวคิดนี้อยู่ในใจตลอดก็น่าจะหลีกเลี่ยงการเขียน Use Case Diagram ในลักษณะที่เป็น Flowchart ได้

หวังว่าบล็อกนี้จะทำให้มีความชัดเจนเกี่ยวกับ Use Case Diagram มากขึ้นไม่มากก็น้อยนะครับ ...