ขั้นตอนวิธีที่จะช่วยเพิ่มความปลอดภัยในระบบคลาวด์

นักวิจัยจาก Weizmann Institute และ Massachusetts Institute of Technology (MIT) กำลังจะประสบความสำเร็จในการพัฒนาขั้นตอนวิธีในการใช้งานข้อมูลที่ถูกเข้ารหัสอยู่โดยไม่ต้องถอดรหัสก่อน และหลังจากประมวลผลแล้วยังสามารถสร้างผลลัพธ์ที่อยู่ในรูปแบบการเข้ารหัสได้อีกด้วย ซึ่งงานวิจัยนี้มีการนำเสนอในปีพ.ศ. 2552 โดยนักวิจัยจากมหาวิทยาลัย Stanford คือ Craig Gentry ขั้นตอนวิธีที่เขานำเสนอนั้นมีชื่อว่า Fully Homomorphic Encryption (FHE) แต่ปัญหาของขั้นตอนวิธีนี้คือมันใช้เวลาในการทำงานนานมาก ซึ่งนักวิจัยจากทั้งสองสถาบันข้างต้นได้ปรับปรุงขั้นตอนวิธีการดังกล่าวให้ใช้เวลาประมวลผลน้อยลงโดยใช้วิธีการทางคณิตศาตร์ที่ีง่ายขึ้น ซึ่งตามข่าวบอกว่าอาจเร็วขึ้น 100 เท่า หรือ อาจถึง 1000 เท่า ผลที่ได้จากงานวิจัยนี้จะมีประโยชน์กับงานที่เกี่ยวข้องกับข้อมูล ซึ่งในปัจจุบันนี้ข้อมูลต่าง ๆ นิยมเก็บไว้ในระบบคลาวด์ โดยข้อมูลถึงจะเข้ารหัสเอาไว้แต่ในวิธีการใช้งานแบบดั้งเดิมถ้าจะใช้ข้อมูลต้องถอดรหัสข้อมูลก่อน ซึ่งในขั้นตอนนี้อาจเป็นปัญหาด้านความปลอดภัยได้ งานวิจัยนี้จึงน่าจะตอบโจทย์ในส่วนนี้ได้

ที่มา: Weizmann Wonder Wander

ทำไมผมถึงรักในหลวง

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

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

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

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

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

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

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

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

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

ข้อดีของการที่ 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 จะเป็นอย่างไร 

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

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 มากขึ้นไม่มากก็น้อยนะครับ ...