ภาพหนึ่งภาพแทนคำล้านคำ ดังนั้น ผมคิดว่าคนที่กำลังศึกษา Facebook Credits อยู่คงจะเข้าใจ ส่วนคนที่ยังไม่เคยศึกษาแต่กำลังคิดจะศึกษา เห็นแล้วก็คงจะพอเข้าใจได้เหมือนกันว่า จุดสำคัญของการเชื่อมโยงกับ Facebook Credits อยู่ตรงการ Callback ซึ่งจะแอบซ่อนอยู่ในส่วนของ PHP เป็นสำคัญ

ทาง Facebook ได้กำหนดลำดับขั้นของ Facebook Credits ไว้ 3 ขั้นอันได้แก่ Info, Placed และ Settled โดยให้ Callback ของแอ็ปของเรา เป็นตัวกำหนดและปรับเปลี่ยนลำดับขั้นโดยการตัดสินใจของแอ็บเราเอง

ส่วนจะข้ามขั้นตอนจาก Info ไป Settled ได้เลยหรือเปล่า อันนี้ไม่เคยลองเหมือนกัน

ผมเองก็ต้องเปลี่ยนกลไกของเกมของผมเหมือนกัน คือเปลี่ยนจาก “วิธีการชำระเงิน” ด้วย PayPal มาเป็น Facebook Credits โดยขอคงสิทธิ์ของ “เงินตราเสมือนจริง” ในเกมของตนเองเอาไว้ ไม่ใช้ Facebook Credits เพื่อเป็น “เงินตราเสมือนจริง” แต่ประการใด!!!

ทีนี้โดยทางเทคนิคต้องทำยังไงบ้างล่ะ? ก็ต้องโยนโค้ดที่ใช้เชื่อมโยงกับ Web Services ของ PayPal ทิ้งไปสินะ แล้วจากนั้นก็เชื่อมโยงกับ Facebook Credits ผ่านทาง SDK (Javascript + PHP) ที่ทาง Facebook จัดเตรียมเอาไว้ให้ พร้อมทั้งเข้าไปอ่านเอกสารของ Facebook เพื่อทำความเข้าใจว่ากลไกของ Facebook Credits อ่ะมันเป็นยังไง

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

และนอกจากนี้ ผมยังได้พบจุดสังเกตในทางเทคนิค เกี่ยวกับ Facebook Credits อีกหลายอย่าง ไม่ว่าจะเป็น …

• ไม่ว่าผู้เล่นจะซื้อหรือไม่ซื้อของ Facebook ก็จะสร้างหมายเลข Order ให้ ถ้ามีการร้องขอ Dialog จาก Facebook
• Facebook Credits API จะส่งข้อมูลที่ไม่ถูกเข้ารหัสมาหนึ่งชุด และข้อมูลที่ถูกเข้ารหัสมาอีกหนึ่งชุด กลับมาที่ Callback ของเรา (ภายหลังจากการร้องขอ Dialog) และเมื่อนำข้อมูลชุดที่สองที่ถูกเข้ารหัสมาถอดรหัสออก เราจะพบว่าข้อมูลที่ได้มันเหมือนเป๊ะกับชุดที่หนึ่งที่ไม่ถูกเข้ารหัสเลยว่ะ ซึ่งก็หมายความว่า Facebook จะให้เราตรวจสอบนั่นเอง ว่าเรากำลังโดน Hack หรือเปล่า โดนโกงโดยการปลอม JSON หรือเปล่า อะไรประมาณนี้
• ตอนวาง Order ผ่านมาเป็น Callback เข้า PHP แต่ตอนจบ Order ดันผ่านมาเป็น Callback ใน Javascript แหม ทำได้ยอกย้อนจริง ๆ
• ต้องไม่เขียนโค้ดให้เว่อร์เกินกว่าที่ Facebook Credits API กำหนดไว้ ยกตัวอย่างเช่น ถ้าเขาให้กำหนด Callback เป็น Function แยกต่างหาก ก็ต้องทำตามเขา อย่าบ้าพลังไปผนวก Callback เข้ากับ Function ที่จะเรียกมัน หรือพูดง่าย ๆ ก็คือ Facebook Credits API มันยังอ่อนแออยู่ ยังมีจุกจิกปัญหาเล็ก ๆ น้อยอยู่

แต่พอผ่านไปผมก็พบว่า ยิ่งคุยยิ่งยาก ดังนั้น การเขียน flowchart มันไม่พอ มันต้องมีการแบ่งแยกด้วยว่า กระบวนการและข้อมูลในช่วงนั้น ๆ ถูกกระทำโดย Unit ใด ก็เลยกลายเป็นว่าต้องเขียนเป็น workflow แทน

เดี๋ยวนี้อาการหนัก เพราะตั้งแต่ทำ SAP R/3 เลยทำให้รู้ว่า การเขียน workflow แบบพื้น ๆ เพียงอย่างเดียวมันไม่พอ ต้องมีการใส่มิติให้กับมันด้วย เพราะ SAP R/3 มันมีหลาย Module ซะเหลือเกิน แถม Unit แต่ล่ะส่วน ก็ใช้ Module สลับไปสลับมาอีกต่างหาก T-T

ต่อไป ไม่แน่ อาจจะต้องเขียนกันเป็น workflow 3 มิติกันเลยทีเดียวเชียว

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

งั้นมาดูแก่นแท้ของวิธีใช้ Amazon EC2 ที่ยืดหยุ่นกันจริง ๆ กันดีกว่า …

จากภาพข้างบนจะเห็นว่า วิธีออกแบบเพื่อใช้งาน Amazon EC2 ที่ดูที่สุด คือการออกแบบให้แต่ล่ะชิ้นส่วน “แยกจากกัน”

โดยเราต้องมองว่า กระดูกสันหลังหลักที่ทำให้ Amazon EC2 ยืดหยุ่นก็คือ Instance ซึ่งเราสามารถเลือกได้หลายระบบปฏิบัติการ เช่น อาจเป็น Linux หรือ Windows, เลือกได้หลายสมรรถนะ เช่น เอา RAM เยอะ ๆ หรือเอา CPU เยอะ ๆ หรือเอาทั้งสองอย่าง

ดังนั้น ถ้าส่วนของ Instance คือส่วนที่เราต้องเปลี่ยนไปเปลี่ยนมาบ่อย ๆ ตามขนาดการใช้งานของเรา งั้นเราก็ไม่ควรจะเอา Script หรือ File อื่น ๆ หรือ Database (ซึ่งก็คือชุดของ File นั่นแหล่ะ) ไปวางไว้ใน Instance ที่จะทำเป็น Web Container หรือ RDBMS หากแต่ใช้วิธีวางไว้ใน Elastic Block Storage แล้วทำการ Mount ไอ้เจ้า Elastic Block Storage เข้ากับ Instance โดยให้มันมองเห็นเป็น Device นึงแทน (เหมือน External Hard Disk)

จากนั้นก็เข้าไปที่ Apache เพื่อ Configure ให้อ่าน Script จาก Device ที่ Mount เข้ามาใหม่ และเข้าไปที่ MySQL เพื่อ Configure ให้อ่าน/เขียน Databases จาก Device ที่ Mount เข้ามาใหม่ ซึ่งอาจจะเป็นที่เดียวกับ Script หรือคนล่ะที่ก็ได้ อันนี้แล้วแต่เราจะออกแบบ

โดยส่วนตัวผมมองว่าภาพข้างบนเป็นพื้นฐานของสิ่งที่ควรจะเป็น สำหรับระบบที่จะมีคนเข้าใช้งานประมาณซัก … 30,000 คนต่อวัน โดยมีการใช้งานพร้อมกัน 300 คนต่อช่วงเวลา!!!

อือม แต่เอาเข้าจริงแล้วก็ไม่แน่นะ อาจจะใช้ของน้อยกว่านี้ก็ได้ อันนี้แล้วแต่ความเก๋าของแต่ล่ะคน เช่น อาจจะเอา Apache, PHP และ MySQL ไว้บน Instance เดียวกัน แล้วเปิดใช้งาน Elastic Block Storage อันเดียว เพื่อเอาไว้ใส่ทั้ง Script และ Database แล้วพอวันดีคืนดีระบบรับไม่ไหว ก็ค่อยมาขยายกันอีกทีทีหลัง อะไรประมาณนี้

หุ ๆ คนเราอ่ะนะ ถ้าได้ของฟรี ๆ มาใช้ คงไม่ต้องใช้สมองคิดขนาดนี้หรอกเน้อะ?

งานวิจัย Speech Recognition ส่วนใหญ่ จะเน้นในกล่องสีแดงเป็นหลัก บางคนเขาก็เน้นวิจัยในกล่อง “การสังเคราะห์เสียง” ส่วนบางคนก็หันไปวิจัยในกล่อง “การเปรียบเทียบเสียง” แทน อันนี้แล้วแต่ความชอบส่วนบุคคล

ปัจจุบันเป็นที่ยอมรับกันทั่วไป (ในวงการ) ว่า Best Practice ใน “การสังเคราะห์เสียงพูด” ในระบบดิจิทัล ให้กลายเป็นชุดข้อมูลเสียงเพื่อใช้งาน คือการใช้เทคนิค Linear Predictive Coding Model

ในขณะที่ Best Practice ใน “การเปรียบเทียบเสียงพูด” คือการใช้เทคนิค Hidden Markov Model

ดังนั้นตอนนี้ นักวิจัยส่วนใหญ่เขาก็เลยไม่มานั่งค้นหา Best Practice กันอีกต่อไปแล้ว (เพราะหากันได้แล้ว) แต่เปลี่ยนเป็นค้นหา “โมเดล” ที่ดีที่สุด (ของ Best Practice ที่มี) เพื่อใช้ในกล่องสีแดงในภาพข้างบนแทน

โดยส่วนตัวแล้วมองว่า หนทางในการทำ Speech Recognition ภาษาไทยเชิงพาณิชย์ ยังทอดยาวอีกไกลนักกว่าจะถึงจุดหมาย เพราะเคยอ่านผ่านตามาว่า Microsoft เองก็ยังเคยโดนบ่นเรื่อง Speech API ของเขา (ซึ่งอยู่บน Vista) และ Google เองก็ยังเพิ่งจะกวาดต้อนผู้เชี่ยวชาญด้าน Speech Recognition มาเข้าสังกัด เพื่อสร้างระบบค้นหาด้วยเสียงเมื่อไม่นานมานี้

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

[tags]speech recognition, linear predictive coding, best practice, hidden markov model[/tags]

แต่ทว่าน่าเสียดาย ที่ไม่ใช่ใครก็สามารถจะทำธุรกิจบัตรเงินอิเล็กทรอนิกส์ได้ เพราะกฎหมายกำหนดเอาไว้ว่า จะต้องเป็นบริษัทหรือบริษัทมหาชนที่มีทุนจดทะเบียนบิ๊กบึ้มซึ่งชำระแล้วตั้งแต่ 200 ล้านบาทขึ้นไป อีกทั้งยังต้องได้รับการอนุมัติจากรัฐมนตรีว่าการกระทรวงการคลังอีกต่างหาก

เรียกว่านอกจากเงินต้องหนาเป็นเมตร ๆ แล้ว สายป่านยังต้องยาวไปถึงขอบอวกาศโน่นเลยทีเดียว!!!

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

สำหรับ 5 รายแรกไม่ต้องพูดถึง เพราะเขาตั้งบริษัทบัตรเงินอิเล็กทรอนิกส์ขึ้นมา เพื่อต่อยอดธุรกิจในเครือของตัวเอง หรือที่เรียกด้วยศัพท์สุดหรูทางการตลาดว่า “Convergence”!!!

รายที่จะโม้ถึงคือรายสุดท้ายต่างหาก เพราะว่าเขาเป็นแสงทองส่องอำไพสำหรับคนทำธุรกิจ e-Commerce, Web Site, Software as a Service, Platform as a Service, Infra-structure as a Service และ Everything as a Service ของเมืองไทย!!!

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

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

จะเห็นว่า (คลิกเพื่อดูภาพขยาย) ไม่ว่าเงินจะวิ่งผ่านจากตรงไหนไปตรงไหน ก็สามารถจะหักค่าธรรมเนียมเอามาเป็นรายได้ ๆ ทั้งนั้น อือม แต่เท่าที่ผมดู รู้สึกว่าจะหักยุบหักยิบยิ่งกว่า Paypal ซะอีกนะเนี่ย T-T ง่ะ

[tags]กระแสเงินสด,บัตรเงิน,อิเล็กทรอนิกส์,บัตรเงินอิเล็กทรอนิกส์[/tags]

ส่วนแบบสองก็เป็นแบบข้างล่าง

สีแดงคือค่าใช้จ่ายที่จะต้องจ่าย หากคิดจะใช้บริการ(มัน) (ซึ่งบางอันอาจไม่ต้องใช้ก็ได้)!!!

แนวคิดไม่ว่าจะเป็นแบบรวมหรือแบบแยกก็คือ ต้องเชื่อม Database Instance กับ Elastic Block Store เพื่อกันเหนียวเอาไว้ เผื่อ Database Instance มันเกิดล่มขึ้นมา และเพื่อเป็นการทำแผนซ้อนสองชั้น เผื่อว่า Elastic Block Store มันดันล่มซะเอง ก็ให้ทำการเชื่อม Elastic Block Store เข้ากับ Bucket ใน Amazon S3 ด้วย Snapshop to Amazon S3 อีกทอดหนึ่ง!!!

ส่วนไฟล์ที่มีการ upload ขึ้นมา ไม่ว่าจะเป็นโปรแกรม, รูปภาพ, เสียง หรือคลิปวีดีโอ ก็ให้ Application Instance โยนไปเก็บเอาไว้ที่ Bucket ใน Amazon S3 เลย เผื่อว่า Application Instance มันล่มขึ้นมา จะได้กู้เฉพาะส่วนของ Framework อย่างเดียวก็พอ!

อือม แบบนี้มันคงจะดีกว่าจ่ายให้กับ Dedicated Server หรือ Co-Location นะ … คิดว่างั้น!!!

[tags]Amazon, EC2, S3, Elastic Block Store, Elastic IP Address, Bucket, Snapshot[/tags]

จากผังงานจะเห็นว่าความรักไม่ใช่สิ่งซับซ้อนอะไรเลย จริงจริ๊ง!!!

[tags]ผังงาน,อธิบาย,สามเหลี่ยม,ความรัก[/tags]

เมื่อวาดออกมาเป็น Multitier เราก็จะเห็นว่าโดยภาพรวมแล้ว OpenX มีงานใหญ่ ๆ เพียงสองงาน คือ การ configure หรือก็คือการปรับแต่งค่าต่าง ๆ และการ display หรือก็คือการแสดงผลโฆษณา!!!

ปัญหาของเราก็คือกลไกการปรับแต่งค่า, ส่วนของการบันทึกค่า และส่วนของการแสดงผลลัพท์จากการปรับแต่งค่านั้น มันมีความซับซ้อนสูงมาก อีกทั้งก็ไม่ได้สนับสนุนภาษาไทยอีกต่างหาก ดังนั้นส่วนนี้เราต้องแก้ไขอย่างช่วยไม่ได้

สำหรับกลไกการแสดงผลโฆษณาไม่จำเป็นต้องไปแก้ไขมัน ปล่อยมันไป!!!

ดังนั้นที่คิดออกมาได้ว่าจะต้องปรับแต่งยังไง ก็จะเป็นดังภาพข้างล่างนี้ …

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

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

การแข่งขันในเรื่องของการบริหารจัดการโฆษณา คงจะต้องวัดกันที่ความเจนจัดและเชี่ยวชาญในการปรับแต่งเครื่องมือแล้วกระมัง ว่าใครจะสามารถนำเอา opensource มา fork ได้ดีกว่ากัน

[tags]OpenX,opensource,fork,ซอฟต์แวร์,คอมพิวเตอร์,multitier[/tags]

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

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

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

ดังนั้นผมจึงขอนำเสนอผังงานที่สามารถสื่อถึงความหมาย และเข้าถึงอารมณ์ความรู้สึกของผู้ชม ผ่านทางผังงานข้างล่างนี้ครับ

(คลิ๊กที่ภาพเพื่อขยาย)

เมื่อดูผังงานแล้วจะเข้าใจว่า มนุษย์ปุถุชนอย่างพวกเรานั้น มีพื้นฐานวัฐจักรชีวิตแค่เนี้ย จริง ๆ ^-^

[tags]ผังงาน,คอมพิวเตอร์,วัฐจักร,มนุษย์,ปุถุชน[/tags]