คลังเก็บหมวดหมู่: WorkFlow

เล่าอะไรก็ได้ด้วย WorkFlow

Callback ของ Facebook Credits

คราวที่แล้วผมเพิ่งจะอธิบายกลไกของ Facebook Credits ไป แต่ว่ามันยังไม่ค่อยจะละเอียดซักเท่าไหร่ งั้นคราวนี้เอาใหม่เลยแล้วกัน เอาแบบละเอียด ๆ ถึงกึ๋นไปเลย บอกกันเจ๋ง ๆ ไปเลยว่ากลไกต่าง ๆ มันเกิดจังหวะไหนบ้าง แล้วก็เกิดตรงไหนบ้าง

Callback ของ Facebook Credits

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

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

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

ใช้ Facebook Credits

ด้วยนโยบายอันเข้มงวดเด็ดขาดและโลภของ Facebook ซึ่งกำหนดให้ผู้พัฒนาเกมบน Facebook ต้องใช้ Facebook Credits เพื่อเป็น “เงินตราเสมือนจริง” หรือ “วิธีการชำระเงิน” บน Facebook แต่เพียงช่องทางเดียว จึงทำให้เกิดความเดือดร้อนเล็ก ๆ แก่ผู้พัฒนาเกมบน Facebook ที่จำต้องเปลี่ยนแปลง “วิธีการชำระเงิน” ของตัวเอง มาใช้ Facebook Credits แทน รวมทั้งความเดือดร้อนใหญ่ ๆ ที่ต้องจ่ายส่วยให้กับทาง Facebook ด้วย!!!

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

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

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

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 มันยังอ่อนแออยู่ ยังมีจุกจิกปัญหาเล็ก ๆ น้อยอยู่

Cross Function Workflow

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

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

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

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

วิธีใช้ Amazon EC2 แบบยืดหยุ่น

คิดว่าคงมีหลาย ๆ คนที่เข้าใจแนวคิดว่า Amazon EC2 เป็นบริการ Cloud Computing ซึ่งเป็นอะไรที่ยืดหยุ่น ขยายได้ หดได้ ตามการใช้งานของเรา

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

งั้นมาดูแก่นแท้ของวิธีใช้ 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 แล้วพอวันดีคืนดีระบบรับไม่ไหว ก็ค่อยมาขยายกันอีกทีทีหลัง อะไรประมาณนี้

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