What is Well-Architected structure ?

เดือนที่แล้วไม่ได้มาเขียนอ่ะ เพราะงานยุ่งกว่าจะนึกได้ก็เดือนใหม่ซะแล้ว ฮ่าๆ รอบนี้ก็หนีไม่พ้นไปแปลงานภาษาอังกฤษมาให้ฟังอีกแหละ เข้าเรื่องเลยดีกว่าเนาะในหลายโพสที่ผ่านมาได้มีการแนะนำ Google App Engine ซึ่งเป็นแบบเอาโค้ดเราขึ้นไป Deploy บนคลาวด์ของ Google ได้นั่นเอง รอบนี้มีของอีกเจ้าหนึ่งที่ก็ดังไม่แพ้กัน นั่นคือ AWS ซึ่งอยู่ในเครือ Amazon โดยอันนี้มีให้เลือกเยอะกว่า GAE หน่อย มีทั้งสามารถสร้าง Infrastructure ได้เอง และแบบคล้ายคลึงกับ GAE คือส่งแค่โค้ดขึ้นไป Deploy บนระบบของ AWS บอกเลยว่าผู้เขียนไม่ได้รับค่าโฆษณาใดๆ ทั้งสิ้นนะ

ผู้เขียนได้ไปอ่านบทความของ AWS ซึ่งนับว่าเป็นบทความที่ดีมากเลย เกี่ยวกับว่าทำไมเราต้องนำระบบไปทำงานบนคลาวด์ จนถึงว่าวางระบบบนคลาวด์ยังไงให้ได้ประโยชน์มากที่สุด โดยแปลมาจาก Whitepaper ของ AWS ชื่อว่า AWS Well-Architected Framework หากเราคิดว่ามันเป็นการโฆษณาเพื่อให้ขายของตัวเองได้ดีขึ้นผู้อ่านก็คิดถูกแล้วแหละ แต่ในโฆษณาก็มีประเด็นที่น่าเก็บเอามาคิดดี เช่น

ในบทความกล่าวถึง การวางระบบบนคลาวด์ AWS พื้นฐานควรทำอย่างไรบ้าง

  • เลิกเดาว่าจะมีคนใช้ระบบกี่คน ในระบบแบบที่เราเป็นคนตั้งเองจำเป็นต้องคำนึงถึงผู้ใช้เพราะไม่งั้นระบบจะล่มเอาได้ง่ายๆ หากเรามัวแต่คิดว่าต้องตั้ง Server กี่ตัว ตั้งมาแล้วไม่ได้ใช้ ตั้งมาแล้วใช้ไม่พอ แบบนี้คงเหนื่อย แต่บน AWS เราไม่จำเป็นต้องเดาอะไรให้มากมายเพราะทุกอย่างเป็นคลาวด์สามารถเพิ่มลดได้ตามความต้องการ
  • สามารถเทสได้บนระบบจริง การเทสถ้าไปเทสกับของจริงเกิดมันล่ม จะทำให้เกิดหายนะ แต่จะสร้างระบบจำลองที่เหมือนของจริงก็ใช้เงินมากทีเดียว เช่น จะต้องนำระบบไป Deploy บนเครื่อง Mainframe ของบริษัท จะให้ทดลองโดยการซื้อ Mainframe อีกเครื่องมาตั้งไว้แค่เทสก็ไม่ไหว แต่บนคลาวด์ทุกอย่างเป็นการแชร์กับคนอื่นอยู่แล้ว สามารถสร้างระบบจำลองอีกทั้งระบบเพื่อใช้แค่วันเดียวในการเทสก็ทำได้
  • ลดความเสี่ยงที่เกิดจาก infrastructure บอกเลยว่าการนำระบบไป Deploy ให้ลูกค้า เครื่องที่ลูกค้านำมาให้ใช้ในการ Deploy เนี่ยไม่รู้ว่าเวอร์ชันตรงกับที่เราพัฒนามารึเปล่าก็ไม่ทราบ แต่การที่ทุกอย่างอยู่บนคลาวด์เราสามารถสร้าง Infrastructure แบบที่เราต้องการได้ ไม่ต้องเสี่ยงกับ infrastructure ที่ไม่พร้อมให้เราทำการ Deploy (ข้อนี้จริงๆ ระบบสามารถอยู่บนแค่ Virtual System ไม่จำเป็นต้องคลาวด์ก็ได้นะ)
  • สามารถทำเวอร์ชันของ infrastructure ได้ ในชีวิตจริงแล้วเนี่ย หากเราต้องเทสระบบแล้วต้องไปลงโปรแกรมบนเครื่องเทสเนี่ย ส่วนมากจะเกิดอาการงงว่าเราลงอะไรไปแล้วบ้างพอระบบมีปัญหาก็ Format แล้วลงโปรแกรมใหม่ แต่นั่นคือถ้ามีเครื่องเพียงเครื่องเดียวชีวิตก็สวยงามดีแหละ หากถ้าเครื่องคำนวณแยกเครื่องกับ Database และแยกกับ Firewall เนี่ยการไปไล่ Format ทั้งหมดคงลำบากมากนะบอกเลย จะดีกว่ามั้ยถ้าเรามีระบบเวอร์ชันให้กับทุกเครื่องที่เกี่ยวข้องกับการเทสของเรา บน AWS สามารถทำเวอร์ชันให้กับเครื่องของเราได้และสามารถเปรียบเทียบความแตกต่างของเวอร์ชันต่างๆได้อีกด้วย (ข้อนี้ผู้เขียนก็คิดเหมือนข้อที่แล้วนะ ถ้าอยู่บน Virtual System อะไรก็ทำเวอร์ชันได้แหละแต่เหนื่อยหน่อยเท่านั้นเอง เพราะ AWS มีระบบเวอร์ชันให้อยู่แล้วเนี่ยแหละเลยง่ายกว่า)
  • รองรับการเปลี่ยนแปลงแบบพลิกฝ่ามือได้ ผู้เขียนแปลออกมาซะยิ่งใหญ่เชียว เพราะคิดว่าอันนี้เป็นข้อดีของระบบ AWS ที่สุดละ อันอื่นอาจจะมีทางแก้ในแนวทางอื่นๆได้ แต่ข้อนี้อาจจะทำไม่ได้ในระบบแบบเก่า โดยในข้อนี้พูดถึงการอยากจะเปลี่ยนแปลงระบบทั้งหมดเช่น เมื่อก่อนเป็น Centralize อยากเปลี่ยนเป็นแบบ Distribution โหไหนจะซื้อเครื่องมาเพิ่มใหม่ ไหนจะเอาเครื่องเก่าไปทำอย่างอื่นอีก โหเหนื่อย แต่ถ้าเป็นคลาวด์ทุกอย่างสามารถหายวับไปกับตาแล้วแทนที่ด้วยสิ่งใหม่เพียงไม่กี่คลิกได้นับว่าเป็นข้อดีอย่างที่สุดของ AWS แล้วสามารถเพิ่มลดทุกอย่างได้ดั่งใจ

นอกจากการออกแบบ infrastructure จะคิดถึงปัจจัยข้างบนแล้ว เวลาออกแบบระบบใดๆก็ตามควรจะคิดถึง 4 ปัจจัยนี้เป็นหลัก คือ ความปลอดภัย (Security) , ความน่าไว้วางใจ (Reliability) , ประสิทธิภาพการใช้งาน (Performance Efficiency) และ การลดค่าใช้จ่าย (Cost Optimization)

Security ในระบบทุกระบบจำเป็นที่เราจะต้องมีการคำนึงถึงความปลอดภัย ซึ่งประกอบด้วย 4 หัวข้อใหญ่ คือ การป้องกันดาต้า (Data protection) , การควบคุมการเข้าถึง (Privilege management) , การป้องกันโครงสร้าง (Infrastructure protection) เช่น การป้องกันการเข้าถึง router และ ระบบควบคุมการตรวจสอบ (Detective controls) เช่น ตั้งให้ระบบมีการตรวจจับการโจมตีอัตโนมัติ

Reliability ระบบจะมีความน่าไว้วางใจเมื่อระบบมีการรองรับความผิดพลาดที่ดี เช่นระบบไม่มี Downtime ในการขึ้นระบบใหม่ ระบบมีการทำ Change management เมื่อระบบที่ขึ้นใหม่มีการเปลี่ยนแปลงจากระบบเก่า และสุดท้ายเมื่อระบบพบกับความผิดพลาดสามารถซ่อมแซมได้ง่ายไม่ใช่ต้องใช้เวลานานในการซ่อมแซม

Performance Efficiency ระบบที่ดีควรมีการจัดสรรทรัพยากรที่ดี เช่นเครื่องที่ทำงานต้องไม่ว่างจนเกินไป นอกจากนั้นทั้งเนื้อที่ความจุและ Database ก็ควรมีประสิทธิภาพเช่นกัน เช่นเราควรเลือก Database และ Storage ให้เหมาะสมกับระบบที่เราจะทำงานด้วย นอกนั้นยังมีเรื่องที่น่าสนใจอีกเรื่องคือการทำแคชเพราะการทำแคชจะเป็นการทำ Space-time trade-off หรือหากเราต้องการความเร็วเพิ่มขึ้นเราสามารถเพิ่มพื้นที่ให้ระบบเร็วขึ้นได้ แต่เราจะสามารถทำแคชได้ง่ายหรือไม่ขึ้นอยู่กับการออกแบบนี่แหละ

Cost Optimization ระบบคลาวด์สามารถคำนวณงบประมาณที่ใช้ได้ง่าย และนอกจากนั้นใน AWS ยังมีระบบที่คิดเงินเป็น API call อีกด้วยหากเรายังไม่ต้องการที่จะสร้าง Server ขึ้นมาใช้จริงๆ นอกจากนั้นทุกอย่างบนโลกนี้เป็นเงินหมดครับ การที่เราไปฝากเครื่องไว้ที่ Datacenter การจะแบ็คอัพทีนี่คิดเงินเยอะประมาณหนึ่งเลยทีเดียวแต่บนคลาวด์ทุกอย่างสามารถลดค่าใช้จ่ายลงได้ครับ

โพสนี้ยาวหน่อยแต่ก็หวังว่าจะเป็นความรู้ให้ผู้อ่านแหละใครสนใจก็ไปอ่านเพิ่มเติมได้ครับ ถ้ายังไม่สนใจยังไง AWS มีโปรฟรีหนึ่งปีสำหรับผู้เข้าไปใช้ใหม่ได้นะครับ นอกจากนั้นเดี๋ยวนี้ AWS พัฒนาหลายระบบขึ้นมาตอบสนองผู้ใช้อีกมากมายลองไปดูกันครับ นอกจากนั้น AWS ยังมี guideline สำหรับระบบต่างๆว่าควรจะวางอย่างไรโดยเข้าไปดูได้ที่ link นี้ครับ

Advertisements

Evolution of Recommendation Systems

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

ในปัจจุบันการเลือกซื้อสินค้า เข้าร้านอาหาร และดูภาพยนตร์ ต้องบอกเลยว่าถูกชักจูงจากระบบ Recommendation System (ย่อยสั้นๆ ว่า RS ละกัน) เป็นส่วนมาก RS  เปลี่ยนพฤติกรรมผู้ใช้ไปมาก คอยแนะนำ คอยชักจูง บางทีเรายังไม่รู้เลยว่าเราต้องการอะไร RS อาจจะรู้ความต้องการมากกว่าเราซะอีก

RS คือระบบคัดกรองข้อมูลอัจฉริยะ ซึ่งช่วยลดตัวเลือกที่จะนำแสนอแก่ผู้ใช้ให้ตรงผู้ใช้มากขึ้น และในปัจจุบันระบบส่วนมากมีการนำ RS เข้าไปใช้งาน ผู้อ่านลองคิดดูสิว่าถ้า Netflix ไม่แนะนำภาพยนตร์ Amazon ไม่แนะนำหนังสือประเภทเดียวกัน Facebook หรือ LinkedIn ไม่แนะนำคนที่น่าจะรู้จัก Yahoo ไม่แนะนำข่าวสารที่น่าสนใจให้ เว็ปเหล่านี้คงขาดความน่าสนใจลงไปโขเลยทีเดียว

คราวนี้เรามาดูกันดีกว่าว่า RS มีส่วนประกอบอะไรบ้าง สำหรับข้อมูลหรือเชื้อเพลิงในการขับเคลื่อนระบบ RS นั้นมีอยู่ 2 อย่างด้วยกัน นั่นคือ Explicit interaction และ Implicit interaction โดย Explicit คือ ข้อมูลโดยตรงที่ได้จากผู้ใช้นั่นเอง เช่น เพศ อายุ เป็นต้น และ Implicit คือข้อมูลโดยอ้อมที่เกี่ยวข้องกับผู้ใช้ เช่น ที่อยู่ปัจจุบัน วันเวลา อุปกรณ์ที่ผู้ใช้ใช้งาน เป็นต้น ยกตัวอย่าง เช่น Amazon ใช้ข้อมูลสินค้าเก่าที่เราเคยเข้าไปดู (Explicit) สินค้าที่ผู้ใช้คนอื่นที่ใกล้เคียงกับเราซื้อ (Implicit) วันเวลาที่ผู้ใช้ใช้งาน (Implicit) จากข้อมูลเหล่านี้ ระบบ RS แบ่งออกได้เป็น 3 ประเภทคร่าวๆ ดังนี้

Collaborative Filtering คือระบบ RS ที่ใช้ข้อมูลการกระทำของเราและเพื่อน เพื่อใช้แนะนำการกระทำที่เราน่าจะทำหรือน่าสนใจ แต่ระบบนี้มีปัญหา Cold Start Problem หรือคือการที่ต้องมีข้อมูลเยอะพอสมควรเพื่อเป็นฐานข้อมูลในการแนะนำ และนอกจากนั้นระบบแบบนี้จะแนะนำการกระทำที่เป็นกระแสในช่วงนั้น โดยไม่แนะนำการกระทำนอกกระแส ก็เป็นข้อเสียเปรียบของระบบ RS แบบนี้ก็ว่าได้ ระบบ RS นี้ยกตัวอย่าง เช่น Amazon, Facebook, Twitter, LinkedIn, Spotify, Google News และ Last.fm

Content-Based Filtering (CBF) คือระบบ RS ที่สนใจในวัตถุนั้นมากกว่าการกระทำของผู้ใช้ โดยการแยกแยะปัจจัยของวัตถุนั้นๆ และแนะนำวัตถุที่มีปัจจัยใกล้เคียงกันขึ้นมาให้ ข้อดีของระบบ RS แบบนี้คือการที่ไม่จำเป็นต้องใช้ข้อมูลมหาศาลในการประมวลผล หรือไม่มี Cold Start นั่นเอง แต่ก็มีข้อเสียอยู่ว่าวัตถุที่แนะนำนั้นค่อนข้างเจาะจงมากไปหน่อย ขึ้นอยู่กับการคำนวนความใกล้เคียงของวัตถุนั้นๆ ตัวอย่างเช่น IMDB, Rotten Tomatoes และ Pandora

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

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

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

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

Mashape : api search engine

ก็วันนี้ไม่มีอะไรมาก จะมาแนะนำ เว็บสำหรับคนหา api (mashape) ซึ่งทำออกมาได้ดีมากเลยทีเดียว เป็นเว็บสำหรับให้ผู้ใช้และผู้สร้างได้เชื่อมต่อกันง่ายขึ้น โดยชีวิตปกติของโปรแกรมเมอร์นั้นส่วนมากก็จะไปหาว่า api ไหนเจ๋งและน่าใช้ใน  stackoverflow ถ้ายังงงกับการทำงานก็จะหาต่อใน Github ซึ่งทำให้ไม่รู้การเชื่อมต่อไปยัง api จริงๆว่าต้องทำอย่างไร ทำให้เสียเวลากับการหา api และนำมาเปรียบเทียบค่อนข้างยาก mashape จะช่วยเติมเต็มความต้องการเหล่านี้

สำหรับฝั่งผู้ใช้นั้น เว็บ mashape สามารถทำให้เราได้ทดลองใช้ api ได้เร็วขึ้น ติดตามการเปลี่ยนแปลงได้อย่างรวดเร็ว และมีการรองรับถึง 8 ช่องทาง (Curl, Java, Node, PHP, Python, Ruby, Objective C, และ .NET) น่าจะเรียกได้ว่าเป็น one-stop service จริงๆ นอกจากนั้นยังมีเว็บบอร์ดสำหรับพูดคุยถามปัญหากับผู้สร้างได้ นอกจากนั้นตัว mashape เองยังมีระบบจัดการรองรับการทำงานทั้ง การกำหนดสิทธ์ผู้เข้าถึง การแปลงข้อมูลให้เหมาะกับ application ของผู้ใช้ มีทั้ง pricing ให้เราดูด้วยว่า api ไหนราคาเท่าไหร่ และยังสามารถดูแลตรวจสอบ api ได้จากที่หน้าเว็บเพียงแห่งเดียวไม่ต้องเข้าหลายเว็บ นั่นคือมาที่หน้าเว็บนี้ทีเดียวรู้หมดว่า api ไหนเป็นอย่างไรบ้าง และเค้ายังรับประกันว่า 99.9% up time หลายคนอาจจะสงสัยว่าเค้าทำฟรีแล้วได้อะไร หากเราเสียเงินให้เค้าไปแล้วเนี่ย (25$ ต่อเดือน) เค้าจะอนุญาตให้เราเค้าถึง api ที่ไม่ public ให้เราเข้าไปยัง api ที่เค้าขายกันจริงๆ ไม่ opensource ไม่เลิกพัฒนาเป็นต้น สำหรับคนที่เป็นองค์กร สมัครไว้ก็ดีนะ

และหากเป็นผู้สร้าง api ก็บอกได้เลยว่าเป็นแหล่งค้าขายที่น่าทำตลาดมาก เพราะผู้ใช้อยากได้แหล่งหา api อยู่แล้วที่ไม่ใช่ google และ overflow เพราะ mashape จัดการให้เราหมดทุกอย่างเลย ทำให้เราไม่ต้องไปหา layout การจะพูดคุยกับลูกค้าว่าทำยังไงให้เค้ามาใช้ mashape จะจัดรูปแบบให้ผู้ใช้เข้าใจง่าย ทั้งยังมีระบบจัดทำรายงานให้ได้วิเคราะห์ และเรายังไม่ต้องกังวลเรื่องระบบของผู้ใช้ว่าจะใช้ข้อมูลแบบไหน mashape จะแปลงข้อมูลตามที่ผู้ใช้ต้องการ และยังเป็น auto-generate sdk ทั้ง 8 ช่องทางให้อีกด้วย บอกได้เลยว่าเจ๋ง ส่วนของผู้สร้างอาจจะอธิบายไม่ค่อยเห็นภาพเพราะเป็นแต่ผู้ใช้ไง แต่บอกผู้สร้างได้เลยนะว่าเป็นตลาดที่น่าสนใจทีเดียว dev ทุกคนอยากได้เว็บอย่างนี้อยู่แล้ว

สำหรับวันนี้ไม่รูปนะเพราะทำไม่ทันอ่ะ แล้วมันสิ้นเดือนแล้วด้วยไว้คราวหน้าละกันนะ

Using Email with Google App Engine

สวัสดีครับ วันนี้อยากแนะนำ cloud ของ google (ไม่ได้เงินค่าโฆษณาแต่อย่างใด) สำหรับใครที่มองหา Server ฟรีสำหรับทำโปรเจคส่งอาจารย์ เช่น โปรเจคเกี่ยวกับ IoT (Internet of Things) ถ้าเงินไม่มีแนะนำ Google App Engine ครับฟรีถึงแม้โควต้าจะไม่เยอะเท่าไหร่แต่ก็ทำให้ได้ Server ดีๆ ได้เลยทีเดียว ลองเข้าไปศึกษากันได้ที่ Google Cloud Platform

สำหรับ Google App Engine รองรับหลายภาษาไม่ว่าจะเป็น Python Java PHP และ Go (ซึ่งในที่นี้ผมถนัด Python นะบอกเลย–น่าจะเดาได้จากหลายๆ โพสที่ผ่านมา) สำหรับฐานข้อมูลนั้นไม่ได้มี MySQL หรือ MongoDB ที่หลายคนถนัดต้องใช้ App Engine Datastore ซึ่งมีโควต้านับเป็นจำนวนครั้งในการอ่านเขียน และโควต้าของ GAE นั้นนับเป็นวันครับ ถ้าวันนั้นใช้เกินโควต้าเว็บหรือเซอร์วิสที่เราพัฒนาจะไม่สามารถเข้าใช้งานได้ ก็รอไปจนครบ 24 ชม (ระหว่างนั้นก็ไปช้อปปิ้ง เล่นเกม) แล้วระบบจะรีเซ็ทให้เหลือศูนย์ใหม่ แล้วก็จะเข้าเว็บได้เหมือนเดิม เหมาะสำหรับผู้ริเริ่มอะไรใหม่ๆ

วันนี้จะแนะนำการใช้เซอร์วิส Email ของ GAE นะครับ นอกจากจะโฮสเว็บได้แล้วยังมีระบบรับส่งอีเมล์ให้เราได้ใช้อีกด้วย สำหรับโค้ดสามารถหาได้จาก SimpleEmailGAE ซึ่งผมเขียนไว้เองแหละ ผู้อ่านสามารถเอาไปต่อยอดไปศึกษา (เดา) จากโค้ดกันได้แน่นอน โค้ดไม่ได้ซับซ้อนมาก โดยการทำงานของโค้ดคือเมื่อส่งเมล์เข้าเมล์ของแอพนั้น จะทำการส่งเมล์ตอบกลับมาก็เท่านั้นเอง ที่สำคัญคือในไฟล์ app.yaml ใน section handlers ห้ามสลับลำดับมั่วนะครับ เดี๋ยวมันจะทำงานผิด แล้วก็ต้องไปเปลี่ยน sender ในไฟล์ handle_incoming_email.py ให้ตรงกับชื่อแอพที่ลงทะเบียนไว้ด้วยนะครับ

นอกจากนั้น GAE ยังอำนวยความสะดวกให้เราได้โดยที่เราสามารถรัน server แบบ localhost (page – localhost:8080 และ admin panel – localhost:8000) ใน Admin panel สามารถส่งเมล์ ดูข้อมูลที่เราเก็บไว้ใน Datastore และดู log ที่เกิดขึ้นได้ สำหรับการส่งอีเมล์ต้องตั้งค่า SMTP ก่อนถึงจะส่งจาก localhost ได้แต่บน GAE ไม่ต้องตั้งค่าก็ใช้งานได้เลย เมื่อทดสอบได้แล้วก็ลองนำไป Deploy บน GAE ได้เลย

Graphviz with Python

นี่ก็สิ้นเดือนอีกแล้วนะครับ ยังไม่ได้ไปหาเนื้อหาใหม่มาเขียนเลย แต่เนื่องจากตั้งใจไว้ว่าทุกเดือนต้องเขียนอย่างน้อยหนึ่งบทความ วันนี้เลยจะมาเสนอ Tool สำหรับวาดกราฟบน Python สำหรับคนที่จะนำไปทำเขียนเปเปอร์หรืออยากให้โปรแกรมแสดงผลเป็นกราฟนะครับ

Tool ที่จะมานำเสนอชื่อ Graphviz ครับซึ่งสามารถติดตั้งได้โดยคำสั่งข้างล่างนี้ (สำหรับระบบปฎิบัติการ Debian นะครับ)

$ sudo apt-get install graphviz
$ sudo pip install graphviz

สำหรับการใช้งานนะครับ ก็ทำการ import ในโค้ด Python ของเราได้เลย นี่คือตัวอย่างโค้ด

import graphviz as gv

graph = gv.Digraph(format="jpg")
graph.attr('graph',{'rankdir':'LR','splines':'ortho'})

layer = [7,6,5,3,3]
layer_name = ['input', 'L1 AE', 'L2 AE', 'L3 AE', 'output']

# init node
layers = []
for layer_id in range(len(layer)):
        layers.append([])
        subgraph = gv.Digraph(name="cluster%d" % (layer_id))
        subgraph.attr('graph', {'label':layer_name[layer_id]})
        
        for node_id in range(layer[layer_id]):
                node_name = 'L_%d_%d' % (layer_id, node_id)
                layers[layer_id].append(node_name)
                subgraph.node(node_name, label='')
        graph.subgraph(subgraph)

# init full-connected edges
for layer_id in range(len(layer)-2):
        for node_source in layers[layer_id]:
               for node_sink in layers[layer_id+1]:
                        graph.edge(node_source, node_sink)

# final layer
for node_id in range(3):
        graph.edge('L_3_%d' % (node_id), 'L_4_%d' % (node_id))

filename = graph.render(filename='img/neural_net')
print filename

และนี่คือตัวอย่างของภาพที่ได้จากการรันโค้ดข้างบนครับ

Neural Network Structure

Neural Network Structure

การทำงานของโปรแกรมจะทำงานโดยสร้างไฟล์ชนิด dot ขึ้นมาจากนั้นแปลงไฟล์ dot ให้เป็นไฟล์ภาพ เพราะฉะนั้นถ้าอยากได้กราฟที่สวยหรูกว่านี้ต้องลองดู property ต่างๆ จาก link นี้ได้เลยครับ

Easy Panorama with OpenCV

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

เริ่มจากอย่างแรกต้องลง OpenCV Library (2.4.8) ก่อนละครับ ซึ่งในที่นี้จะเป็นการ install สำหรับ Ubuntu โดยใช้คำสั่งตามนี้ครับ

$ sudo apt-get install libopencv-dev build-essential

จากนั้นก้โหลดโค้ด (stitching.cpp) และภาพ dataset จาก link นี้นะครับ โดยต้องโหลด CMakeLists.txt มาด้วยเพื่อช่วยให้การ build โปรแกรมง่ายขึ้น โดยใช้คำสั่งข้างล่างนี้

$ cmake . && make

เพื่อตรวจสอบว่าโปรแกรมที่ build มานั้นทำงานได้หรือไม่ทำได้โดยการพิมพ์ ./stitching จากนั้นตัวโปรแกรมจะฟ้องให้ใส่ input images เข้าไปครับ เราก็สามารถใส่ภาพที่เตรียมไว้ให้เข้าไปได้โดยใช้คำสั่งดังนี้

$ ./stitching 1.jpg 2.jpg 3.jpg

จากนั้นเราก้จะได้ภาพพาโนราม่าสวยๆ ในไฟล์ result.jpg ตามข้างล่างนี้ครับ

Panorama 1

Panorama 1

Panorama 2

Panorama 2

Kasetsart University

Kasetsart University

ขอขอบคุณภาพจาก P. MONGKOLPITTAYATHORN, NOPPON UMNAJWANNAPHAN

Create Bash-script service for Debian

ในบางครั้ง เราต้องการให้โปรแกรมที่เราเขียนขึ้นรันเมื่อเปิดเครื่องคอมพิวเตอร์ขึ้นมา และใน Debian นั้นสามารถทำได้หลายวิธี ไม่ว่าจะเป็นการสั่งให้เรียกโปรแกรมจากไฟล์ crontab หรือ rc.local ซึ่งในวันนี้จะเสนอวิธีที่นำโปรแกรมมาสร้างเป็น Bash-script แล้วนำไปผูกกับ service ของระบบปฎิบัติการ Debian

การสร้าง Bash-script แล้วจึงนำไปถูกกับ Service มีข้อดีคือ เราสามารถสั่งเปิดปิดโปรแกรมของเรา รวมถึง restart ได้ผ่านทางระบบ service ของ Debian ได้นั่นเอง ซึ่งนี่คือตัวอย่างของวิธีการดังกล่าว PiCam-Setup เป็นการสร้าง Service ในการเปิดกล้องให้กับ Raspberry Pi โดยใช้ไลบรารี่ mpeg-streamer

มาเริ่มกันเลยดีกว่า อย่างแรกที่ต้องมีคือโปรแกรมที่อยากให้ทำงานก่อนในที่ใช้โปรแกรม my_program.py จากนั้นเขียนไฟล์ Bash-script ดังนี้

#!/bin/bash
# /etc/init.d/MyService.sh

function startService()
{
    ./my_program.py &
}

case "$1" in
    start)
        echo "Starting my_program.py"
        startService
        ;;
    stop)
        echo "Stopping my_program.py"
        killall my_program.py
        ;;
    status)
        echo "Not supported yet"
        ;;
    restart)
        echo "Restarting my_program.py"
        killall my_program.py
        start
        sleep 2
        ;;
    *)
        echo "Usage: $0 {start|stop|restart}"
        exit 1
        ;;
esac
exit 0

จากนั้น เราต้องก็อปปี้สคริปข้างบนไปไว้ /etc/init.d/ จากนั้นก้ update-rc.d ตามคำสั่งดังนี้

# cp MyService.sh /etc/init.d/
# chmod +x /etc/init.d/MyService.sh
# update-rc.d MyService.sh defaults

เพียงเท่านี้เราก้จะได้เซอร์วิสที่เป็นของเราเองแล้วครับ