งั้นมาดูวิธีของผมกันดีกว่า เอาแบบจากประสบการณ์จริงกันไปเลย

1. ต้องเลือกก่อนว่าจะเอา Web Application ของเราไปขับเคลื่อนที่ไหน อย่างกรณีของผม ผมใช้บริการ Cloud Computing ของ Amazon Web Services เป็นตัวจัดการเรื่องนี้ โดยเน้นใช้งานแต่บริการของ Amazon EC2 เพื่อเอามาทำเป็น Instance Server จำนวน 2 Instance ให้ Instance นึงไว้ขับเคลื่อน Application และอีก Instance นึงไว้ขับเคลื่อน Database โดยผมเลือกใช้งานโซนแคลิฟอร์เนียเหนือ และเลือกใช้ Image แบบ LAMP หมายเลข ami-1d6a3858 ซึ่งเป็น LAMPStack ที่มีระบบปฏิบัติการเป็น Ubuntu รุ่น 10.04 แบบ 32 bit สอดไส้ด้วย PHP รุ่น 5.3 มี Virtual Core 1 ECU และ RAM 1.7 GB (เล็กชิบเป๋ง)
2. จากนั้นก็โยนโค้ดไว้ที่ Application Instance และโยนฐานข้อมูลไปไว้ที่ Database Instance โดยที่ Database Instance จะพิเศษหน่อย เพราะผมจะไม่ใช้เนื้อที่ของ Database Instance เพื่อเก็บฐานข้อมูล แต่จะใช้ Amazon Elastic Block Store ที่ผมผูกไว้กับ Database Instance เป็นตัวเก็บข้อมูลแทน
3. พอได้ขุมพลังในการขับเคลื่อนและได้ทำการเชื่อมโยง Application Instance กับ Database Instance ผ่านการ Configure อะไรหลาย ๆ อย่างแล้ว ทีนี้ก็ต้องมาดูเรื่อง Domain บ้าง โดยผมได้จดโดเมนเอาไว้ก่อนเรียบร้อยแล้วที่ Go Daddy
4. คราวนี้ก็ต้องเอา Domain ที่จดทะเบียนไว้ ไปผูกโยงเข้ากับ Application Instance ที่เตรียมเอาไว้ก่อนแล้ว โดยผมได้เลือกใช้บริการของ Dynamic DNS แบบ Custom DNS Package จากนั้นก็ Configure ไำอ้เจ้า CNAME กับ A-Records เพื่อเชื่อมโยงระหว่างชื่อ Domain กับเลข IP ของ Application Instance เข้าไว้ด้วยกัน
5. และท้ายที่สุด ก็ต้องกลับไป Configure ที่ Go Daddy เพื่อบอกให้มันรู้ว่า ตกลง Domain ที่ผมจดทะเบียนไว้ มันเชื่อมโยงไปยัง Primary Name Server ใด ซึ่งในที่นี้ก็คือ Primary Name Server ของ Dynamic DNS นั่นเอง โดยผมใส่ลงไป 5 Name Server เลย ใช้มันให้คุ้ม ทำ Load Balancing แบบเว่อร์ ๆ เพราะผมเสียดายมาก เนื่องจาก Package ที่จ่ายตังค์ไป มันเปิดให้เรากำหนด DNS ได้ถึง 75+ Domain แต่ประทานโทษ ผมใช้มันสำหรับ Domain เดียว โคตรเสียดายตังค์เลย T-T

เมื่อเราทำมาถึงขั้นตอนนี้ ก็ถือว่าทุกอย่างเรียบร้อยหมดแล้ว คราวนี้เราก็จะสามารถลองใช้งาน Web Application ของเราได้ โดยการเปิด Web Browser แล้วพิมพ์ URL ของ Domain เราเข้าไป แล้วรอซักชั่วอึดใจมด จากนั้น Web Application ของเราก็จะปรากฎขึ้นมา … อย่างสวยงามเลยทีเดียวเชียว!!!

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

โดยปัญหาอย่างแรกคือปัญหาคลาสสิค นั่นก็คือ พื้นที่จัดเก็บของเครื่องไม่ค่อยจะพอ เพราะถึงแม้จะมี Mobile Application หลาย ๆ ตัว ที่อนุญาตให้เราย้ายไปติดตั้งที่ SD Card ได้ แต่นั่นก็ไม่ใช่ App ทุกตัวที่จะทำได้ แถมยิ่ง Mobile Application มีการปรับรุ่นให้ทันสมัยยิ่งขึ้น มันก็มีขนาดใหญ่โตยิ่งขึ้นไปอีก!!!

ส่วนปัญหาอย่างที่สองอ่ะเด็ดกว่า นั่นคือ ผู้ผลิต Mobile Application ไม่รู้จะรีบไปไหน (สงสัยจะกลัวตกเทรน) ก็เลยตั้งหน้าตั้งตาทำให้ App ของตัวเองทันสมัยกันใหญ่ ผลก็คือ มันใช้ไม่ได้ มันล่ม มันบังคับให้ปิดตัวเอง และก็ไม่อยากจะเชื่อว่าแม้แต่ Facebook for Android เองก็มีปัญหากับเขาเหมือนกัน (หลังจากปรับรุ่นแล้ว)

เมื่อเป็นแบบนี้ ผมก็เลยหันไปใช้บริการของ App นั้น ๆ ผ่านทางเว็บบราวเซอร์ในลักษณะ Web Application แทน!!!

มันทำให้ผมเห็นว่า รูปแบบของ Application จะเริ่มหันเหจากเดิม คือ …

Desktop Application -> Web Application -> Mobile Application

ไปเป็น …

Desktop Web Application -> Mobile Web Application -> Mobile Application

ส่วน Desktop Application ก็คงจะล้าสมัยไปตามระเบียบ เพราะสัดส่วนมันคงจะน้อยลงไปเรื่อย ๆ เนื่องจากตลาดผู้บริโภคหันไปจับกลุ่มที่ Tablet กับ Smart Phone แทน

ตอนนี้ผมเลยเริ่มเห็นแล้วว่า วิธีการควบคุมต้นทุนสำหรับการสร้าง Mobile Application (ที่น่าจะดี) ก็คือ การสร้างให้มันเป็น Mobile Web Application และละทิ้งการสร้าง Mobile Application ที่ยึดโยงต่อระบบปฏิบัติการใด ๆ (Android หรือ iOS หรือ webOS หรือ บลา ๆ ๆ) ซึ่งจะตอบโจทย์ในเรื่องของอรรถประโยชน์และต้นทุนการผลิตมากกว่า (สำหรับการทำเป็นงานอดิเรก)

Container

1. EasyPHP เอาไว้ทดสอบโปรแกรม

Editor

1. Notepad++ เอาไว้เขียนโปรแกรม
2. Photoshop CS5 เอาไว้วาดรูป

Software Developerment Kits

1. Facebook PHP SDK เอาไว้ต่อเชื่อมกับ Facebook ด้วย PHP
2. Facebook Javascript SDK เอาไว้ต่อเชื่อมกับ Facebook ด้วย Javascript เพื่อเสริมลูกเล่นในการตอบโต้
3. jQuery ใช้เพราะขี้เกียจมาทำ Javascript Framework เอง (โดยเฉพาะ AJAX นี่ ขี้เกียจทำเองมากกกกกกกกก)
4. jQueryUI เอาไว้ทำพวก Dialog, Slide และ Tab

Manual (อันนี้สำคัญมาก ถ้าไม่มีนี่ ถึงขนาดหูหนวกตาบอดเลยทีเดียว)

1. Tags HTML เอาไว้หารายละเอียดของ Tag HTML เพราะผมไม่เคยจำ
2. Javascript ไอ้เจ้า Javascript ผมก็ไม่เคยจำ
3. MySQL 5.1 ลำพังคำสั่ง SQL พื้น ๆ น่ะจำไม่ยากหรอก แต่ถ้าเป็นพวกคำสั่งเล็ก ๆ น้อย ๆ เนี่ย จำไม่ได้อ่ะ T-T
4. CSS นี่ผมก็ไม่จำ เวลาจะใช้ก็ค้น ๆ เอา
5. Facebook Graph API พอดีผมเริ่มมาทำ Facebook App ตอนที่ Facebook เปลี่ยน Core API มาเป็น Graph API พอดี ก็เลยไม่ต้องไปอ่านของเก่า ดีเหมือนกัน
6. Facebook Javascript API จำไม่ได้อ่ะ ไม่เคยจำ อาศัยอ่าน ๆ แล้วทำตาม
7. Regular Expression เอาไว้ค้นไวยากรณ์ประหลาด ๆ ที่ไม่ค่อยได้ใช้บ่อยนัก
8. PHP ต้องใช้ เพราะไม่เคยจำคำสั่ง

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

มารที่มารบกวนผม ทำให้ผมพัฒนาเกมฯที่ว่าไปไม่ถึงไหน ไม่ใช่กลไก Facebook, ไม่ใช่ jQuery และไม่ใช่ PHP หากแต่เป็น Web Browser!!!

มันเป็นเรื่องที่แย่มาก ที่ Web Browser ที่ใช้โดยคนส่วนน้อย ไม่ว่าจะเป็น Firefox, Chrome, Opera หรือ Safari ไม่เคยสร้างปัญหาจุกจิกให้กับผมเลย ในขณะที่ Internet Explorer ซึ่งเป็น Web Browser ที่ใช้โดยคนส่วนใหญ่ กลับสร้างปัญหาจุกจิกให้กับผมได้มากมายอย่างยิ่ง

ไอ้อะไรที่ทำบน IE ได้ จะทำบนตัวอื่น ๆ ไม่ได้ และไอ้อะไรที่ทำบนตัวอื่น ๆ ได้ กลับไม่สามารถทำบน IE ได้!!!

เคล็ดอย่างหนึ่งที่ผมพบก็คือ IE เป็น Art ตัวแม่!!! มันจะคอยจับผิดไอ้โน่นไอ้นี่อยู่ตลอดเวลา แต่ไม่เคยบอกเราจริง ๆ แม่น ๆ หรือตรง ๆ ตำแหน่ง ว่าไอ้ที่มันบอกว่าผิดอ่ะ มันตรงไหนกันแน่ บอกอ้อม ๆ อยู่นั่นแหล่ะ ที่สำคัญยังเถรตรงติงต๊องอีกต่างหาก ไอ้บางอย่างที่ Web Browser ตัวอื่นเขาหยวน ๆ มันก็ไม่หยวน

ส่วนไอ้บางอย่างที่ชาวบ้านเขาไม่หยวนแต่มันกลับหยวน!!!

T-T ผมเพิ่งจะได้เข้าใจอย่างลึกซึ้งก็ช่วงนี้นี่แหล่ะ ว่าความรู้สึกเสน่หาต่อ IE ของเหล่าคนไอทีไทยนั้นมันเป็นแบบนี้นี่เอง!

อธิบายภาพข้างบนสั้น ๆ ได้ดังนี้

1. คุณต้องติดตั้ง Facebook Canvas เป็น, เข้าใจใน Facebook Graph API และเข้าใจใน Facebook Client Libraries (ทั้งหมดฟรี)
2. คุณต้องจดทะเบียน Domain (เสียตังค์) กับ Domain Registrar (Domain ที่ว่าก็คือ ไอ้พวก http://www.yourdomain.com อะไรเทือกนั้นแหล่ะ) เช่น Godaddy เป็นต้น
3. คุณต้องจดทะเบียน DNS (เสียตังค์) กับ DNS Provider เพื่อที่คุณจะได้ผูก Domain ของคุณเข้ากับ Amazon EC2 ได้
4. คุณต้องสมัครเพื่อใช้งาน Amazon EC2 (ไม่ต้องเสียตังค์) แล้วเข้าไปสร้าง Application + Db Instance (เสียตังค์ตามการใช้งาน) โดยสร้างขึ้นมาแค่ Instance เดียวก็พอ (ต่อไปถ้าคุณเก่ง คุณสามารถสร้างเยอะ ๆ ก็ได้นะเออ)
5. คุณต้องสร้าง Elastic IP ขึ้นมา (เสียตังค์) เพื่อให้ Instance ของคุณ สามารถติดต่อกับโลกภายนอกได้ โดยสร้างแค่ IP เดียวก็พอ (ก็ใช้แค่ Instance เดียวไง ก็เลยใช้แค่ IP เดียวก็พอ)
6. บังเอิญว่า Instance ใน Amazon EC2 เป็นพวกความจำสั้น ดังนั้น ถ้ามันโดน Restart หรือ Terminate เมื่อไหร่ล่ะก็ มันจะลืมทุกอย่างไปหมดเลย (รวมทั้ง Code และ DB ด้วย) ดังนั้น น่าจะเป็นการดี หากเราจะสร้าง Elastic Block Store ขึ้นมา (เสียตังค์) เพื่อเอามาเป็นที่พักข้อมูลจาก Instance เผื่อว่า Instance มันล่มหรืออะไรยังไง มันจะได้มีตัวสำรอง
7. แต่ถ้าคุณคิดว่า Elastic Block Store จะไม่ชัวร์ กลัวว่าตัวมันเองก็อาจจะล่ม คุณก็สามารถจะติดตั้ง Snapshot To S3 (เสียตังค์) เพื่อให้มันทยอยโอนข้อมูลของคุณ ไปเก็บไว้ใน Bucket (เสียตังค์) ของ Amazon S3 ก็ได้ (คุณต้องสมัครเพื่อขอใช้ Amazon S3 อันนี้ฟรี ไม่เสียตังค์)

สรุปว่าจะประมวลผล Facebook Application บน Amazon EC2 ก็ต้องจ่ายพอตัวเหมือนกัน แต่ถ้าทำออกมาดี ๆ ก็น่่าจะคุ้มอ่ะนะ เพราะถ้าให้ไปประมวลผลบน Shared Hosting ก็คงไม่ได้ เพราะทรัพยากรจำกัดจำเขี่ยเหลือเกิน เกิดผีเข้าผีออก มีคนเข้า Facebook Application ของเราเยอะขึ้นมา ไปทำ Shared Hosting เขาล่ม เดี๋ยวเขาจะเฉดหัวออกมาแทบไม่ทัน

ส่วนจะไปประมวลผลบน Dedicated Server หรือ Virtual Private Server ก็ยุ่งยาก ต้องติดตั้งทุกอย่างเองทั้งหมด (Amazon EC2 มันเทพ สั่งสร้าง Instance โป้งเดียว มันติดตั้งระบบปฏิบัติการและปรับแต่งทุกอย่างให้หมดเลย)

ยิ่งเป็น Co-Location ก็ยิ่งแล้วใหญ่ เพราะเดี๋ยวนี้ฮาร์ดแวร์มันทันสมัยขึ้นแทบทุกวี่ทุกวัน จะให้เช่าซื้อ Server มาเป็นของตัวเองมันจะไม่คุ้ม แบบว่ายังไม่ทันไร Server ที่มีก็ตกยุคซะแล้ว หรือถ้าไม่ตกยุค แต่ต้องมาอัด RAM ทำ Server Farm เองก็หลังแอ่นเหมือนกัน

1. คุณต้องรู้และเข้าใจภาษา PHP ในระดับหนึ่ง (ยิ่งเก่งยิ่งดี) เพราะมันเป็นภาษาทางการในการพัฒนา Facebook Application (ภาษาอื่นก็มี แต่ไม่นับเป็นภาษาทางการ)
2. คุณต้องรู้และเข้าใจหลักการของ Object Oriented Programming ซึ่งผมคิดว่าคนที่เรียนคอมพิวเตอร์มาทุกคน ล้วนเคยถูกกำหนดให้เรียนวิชานี้ทั้งนั้น (สมัยนี้นะ) ส่วนจะเรียนเป็นบทหนึ่งบทในรายวิชา หรือจะเรียนเป็นรายวิชาสามหน่วยกิต อันนี้ก็สุดแล้วแต่
3. คุณต้องรู้และเข้าใจภาษา Javascript ในระดับหนึ่ง (ยิ่งเก่งยิ่งดี) เพราะมันเป็นภาษาที่สร้างลูกเล่นเสริมให้กับ Facebook Application ของคุณ
4. คุณต้องรู้และเข้าใจหลักการของ Web Service เพราะมันเป็นกุญแจสำคัญในการสื่อสารระหว่าง Facebook Application กับ Facebook Platform

ทีนี้เรามาดูเรื่องที่น่าสนใจเรื่องหนึ่งกัน นั่นก็คือ Facebook Application มีทั้งหมด 3 แบบ แบบแรกเป็น Desktop Application, แบบสองเป็น Web Application และแบบสามเป็น Mobile Application

แต่ล่ะแบบล้วนมีพื้นฐานทาง Web Service ที่เหมือนกัน แต่ว่ามีกลไกปลีกย่อยที่แตกต่างกันตาม Platform ของตัวเอง โดยหัวข้อนี้จะเน้นเกี่ยวกับแบบ Web Application เป็นสำคัญ

วิธีการเรียนรู้ที่ดีที่สุดก็คือการเรียนจากคนอื่น (ผมขี้เกียจเขียนอธิบาย) ดังนั้น ขอให้พวกเราเข้าไปดูบทความที่กูรูเขียนเอาไว้แล้วก่อน (เพื่อเป็นการปูพื้นฐาน) ตามหัวข้อข้างล่างนี้

1. เริ่มต้นกับการเขียน Facebook Application สำหรับผู้เริ่มต้น (PHP)
2. เริ่มต้นกับการเขียน Facebook Application สำหรับผู้เริ่มต้น (PHP) (2)
3. เริ่มต้นกับการเขียน Facebook Application สำหรับผู้เริ่มต้น (PHP) (3)
4. เริ่มต้นกับการเขียน Facebook Application สำหรับผู้เริ่มต้น (PHP) (4)
5. เริ่มต้นกับการเขียน Facebook Application สำหรับผู้เริ่มต้น (PHP) ฉบับปรับปรุง Graph API

โอเค ผมจะัถือว่าพวกเราได้อ่านบทความในย่อหน้าข้างบนครบทุกอันแล้วนะ ทีนี้เรามาอธิบายส่วนของพื้นฐาน, การขยายความ และ ส่วนเสริมกันดีกว่า

สิ่งแรกที่จะบอกก็คือ Facebook เขาก็มีพัฒนาการของเขา ดังนั้น เขาย่อมไม่หยุดอยู่กับที่ ปรับโน่นเปลี่ยนนี่ไปเรื่อย ๆ รวมทั้ง API ของเขาด้วย โดยหลังจากที่ปล่อยให้มี API เดิมให้ใช้มาราวสองถึงสามปี จนกระทั่งผู้พัฒนา Facebook Application ใช้กันจนคล่อง ติดกันจนงอมแงมแล้ว เมื่อกลาง (ค่อนปลาย) ปี พ.ศ. 2553 ที่ผ่านมา ทาง Facebook ก็ออก API ตัวใหม่ออกมา นัยว่าเพื่อจะได้ใช้ง่ายขึ้น ดีขึ้น สะดวกขึ้น บลา ๆ ๆ ๆ ๆ โดยประกาศว่าให้ Facebook Application ใหม่ ๆ ที่ถูกสร้างขึ้น จงสร้างด้วย API ใหม่โดยพลัน ส่วน Facebook Application เก่า ๆ จะยังใช้ API เดิมได้อยู่ (แต่คงอีกไม่นาน)

นอกจากนี้ทาง Facebook ก็ตัดสินใจยกเลิกภาษาของตัวเอง (Facebook สร้างภาษา FBML ออกมา มันแบบ คล้าย ๆ กับ HTML แต่ไม่เป็นที่นิยม เลยต้องเลิกไป) แล้วหันไปสนับสนุน IFrame อย่างสุดแรงม้า (เว่อร์จริง ๆ)

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

และที่สำคัญ มีสิ่งหนึ่งที่นักพัฒนา Facebook Application เขารู้ แต่เขาไม่ค่อยเล่าให้ฟังกัน เนื่องจากมองว่ามันเป็นพื้นฐาน มันง่าย ใคร ๆ ก็น่าจะรู้ (ไม่จริงหรอก เรื่องเล็ก ๆ ง่าย ๆ นี่แหล่ะ มีคนไม่รู้เยอะ) นั่นก็คือ Facebook API มองได้เป็น 2 ส่วนใหญ่ ๆ คือ ส่วนของ ข้อตกลง Web Service และส่วนของ SDK!!!

ส่วนของข้อตกลง Web Service อ่ะนะ เป็นมาตรฐานวิธีในการเชื่อมโยงข้อมูลระหว่าง Facebook กับ Facebook Application ของเรา ซึ่งทาง Facebook ทำคู่มือออกมาให้เราอ่านกัน (แบบโคตรละเอียด แต่ กูงง กูงง กูงง) ไม่่ว่าจะเป็นคู่มือที่ชื่อ Apps on Facebook.com (อธิบายตั้งแต่การแสดงตน, ขอใช้สิทธิ์ และทำนู่นทำนี่) หรือ Grarph API (อธิบายว่าการแสดงตน, ขอใช้สิทธิ์ และทำนู่นทำนี่ ต้องส่ง Request แบบ Web Service ไปหา Facebook เป็นจำนวนกี่ท่อน และแต่ล่ะท่อนต้องยัดอะไรใส่เข้าไปบ้าง)

ส่วนของ SDK เป็นโค้ดของโปรแกรมแบบ Open Source ซึ่งพัฒนาขึ้นด้วยภาษาต่าง ๆ เช่น PHP หรือ Javascript เป็นต้น เพื่ออำนวยความสะดวกให้กับเรา ทำให้เราไม่จำเป็นต้องเขียนโค้ดเพื่อทำตามข้อตกลง Web Service ที่ Facebook กำหนดไว้ (มีชาวบ้านเขียนไว้ให้ ว่างั้น)

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

โดย SDK ที่ว่าก็สามารถไปดาวน์โหลดได้ที่ GitHub เลือกโหลดเฉพาะ PHP-SDK (PHP Client Library) กับ Connect-JS (Javascript Client Library) นะ เพราะเป็นสิ่งที่โม้ ๆ อยู่ในหัวข้อนี้ (พอเข้าไปที่หน้าจอได้แล้ว อย่าลืมเหลือบไปดูที่เยื้อง ๆ มุมขวาของ Browser ด้วยล่ะ เพราะแถว ๆ นั้นมีปุ่ม “Download Source” ให้กด ก็กดตรงนั้นนั่นแหล่ะ จะได้ดาวน์โหลดมาทั้งยวงเลย!!!)

ต้องทำความเข้าใจก่อนว่า SDK ก็คือโค้ดที่มาเขียนเพื่อครอบข้อตกลงฯ ดังนั้น มันก็อาจจะเป็นชุดของ Function หรือเป็นชุดของ Class ก็ได้ โดยในที่นี้โค้ดของ PHP Client Library อ่ะเป็น Class ในขณะที่ Javascript Client Library อ่ะเป็น Function

ทีนี้ขึ้นชื่อว่าเป็น Class หรือ Function มันก็ต้องมีคู่มือประกอบใช่แมะ ว่ามันมีพารามิเตอร์อะไรบ้าง, มี Properties อะไรบ้าง หรือมี Method อะไรให้เรียกใช้ได้บ้าง?

ข่าวดีคือ Facebook ทำคู่มือ Javascript Client Library เอาไว้ให้เราอ่านเพื่อทำความเข้าใจนะ แต่ข่าวร้ายคือ Facebook ไม่ได้ทำคู่มือ PHP Client Library เอาไว้ให้อ่ะ มันยังไม่มี ต้องเข้าไปดูในโค้ดของ SDK เอาเอง!!!

มันก็เลยทำให้เราเกิดภาระเล็ก ๆ ขึ้นมา เพราะกลายเป็นว่า นอกจากเราจะต้องเรียนรู้ API ในส่วนของข้อตกลง Web Service แล้ว เรายังต้องมาเรียนรู้เพิ่มเติม (อีกเล็กน้อย) ในการใช้งาน PHP Client Library อีกหรือนี่???

ข้อสรุปอีกอย่างหนึ่งที่เกี่ยวกับ Facebook Application ก็คือ เราสามารถจะเขียน Facebook Application ด้วย PHP Client Library ล้วน ๆ ก็ได้ หรือจะเขียนผสม ๆ กันกับ Javascript Client Library ก็ได้ (อันนี้แล้้วแต่ความจำเป็น) นอกจากนี้ ถ้าเราเขียนมันจนชำนาญแล้ว เราก็ไม่จำเป็นต้องเขียนแบบ Pure PHP อีกต่อไป เพราะเราสามารถใช้ Web Application Framework (ไม่ว่าจะเป็น CakePHP หรือ CodeIgniter) เพื่ออำนวยความสะดวกให้เราเขียน Web Application ได้ง่ายและเร็วอีกด้วย

การจะดูหุ้นเดี๋ยวนี้ไม่เหมือนเมื่อก่อน ที่จะต้องไปยืนดูที่หน้ากระดานที่บริษัทหลักทรัพย์จัดเตรียมเอาไว้ เดี๋ยวนี้เราดูผ่านหน้าจอคอมพิวเตอร์ได้แล้ว แถมถึงขั้นดูผ่านโทรศัพท์มือถือได้ด้วย แต่พวกเรารู้กันบ้างหรือเปล่าว่า กว่าจะมาถึงตอนนี้ได้ โปรแกรมดูหุ้นได้ผ่านวิวัฒนาการอะไรมาบ้าง?

ผมไม่ลงวันที่ชัดเจนนะ เอาจากประสบการณ์ของตัวเองมาเล่าก็แล้วกัน!!

MS-DOS จ๋า จุ๊บ ๆ

ผมได้เห็นโปรแกรมดูหุ้นครั้งแรกเมื่อปี พ.ศ. 2540 ตอนนั้น CEO เรียกให้คนศูนย์คอมพิวเตอร์ไปตรวจสอบคอมพิวเตอร์ เพราะพี่แกดูหุ้นไม่ได้ ซึ่งความซวยมาตกที่ผม ผมก็เลยต้องเป็นคนไปดูให้ เลยได้เห็นว่าโปรแกรมดูหุ้นในตอนนั้น ใช้สั่งซื้อสั่งขายหุ้นไม่ได้ เรียกว่าเอาไว้ดูหุ้นเฉย ๆ จริง ๆ โดยมันเป็นโปรแกรมที่ทำงานบนระบบปฏิบัติการ MS-DOS แสดงผลหน้าจอแบบ Text Mode, เชื่อมต่อกับบริษัทให้บริการข้อมูลหุ้นด้วย MODEM 14.4K ผ่านเบอร์โทรศัพท์เฉพาะที่บริษัทฯจัดเตรียมเอาไว้ให้ลูกค้า ซึ่งผมคิดว่าเขาคงจะใช้ระบบโปรโตคอลแบบปิด ไม่ใช่โปรโตคอลที่แพร่หลายในทุกวันนี้

สรุปตอนนั้นผมไม่มีปัญญาแก้ไขให้เขาได้ เพราะบริษัทที่ให้บริการข้อมูลหุ้นนั่นแหล่ะ ที่ไม่ยอมส่งข้อมูลมาให้เพราะระบบขัดข้อง

Desktop Application ครองโลก

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

โปรแกรมดูหุ้นสมัยนั้น ส่วนใหญ่เขียนขึ้นด้วย Microsoft Visual C++ ดังนั้น ลูกค้าจึงต้องใช้ระบบปฏิบัติการ Microsoft Windows เพื่อใช้งานโปรแกรมดังกล่าว โดยโปรแกรมจะเชื่อมโยงข้อมูลกับบริษัทหลักทรัพย์ผ่านโปรโตคอลแบบปิดของตัวเอง และโปรโตคอลที่ว่าก็ขี่อยู่บนโปรโตคอล TCP/IP อีกทีนึง ลูกค้าก็เลยไม่ต้องหมุน MODEM ไปที่บริษัทหลักทรัพย์ แต่หมุน MODEM ไปยังผู้ให้บริการอินเทอร์เน็ตแทน

Applet มาแล้วจ้า

ผมคิดว่าลูกค้าคนอื่นก็น่าจะคิดเหมือนผม ว่าถ้าเราไปดูหุ้นที่คอมพิวเตอร์เครื่องอื่นที่เราไม่ได้เป็นเจ้าของ เราก็ต้องไปลงโปรแกรมดูหุ้นใหม่ เสียเวลาทำมาหากิน แถมบางทีเครื่องนั้น ๆ อาจจะล็อกสิทธิ์เอาไว้ ไม่ให้เราติดตั้งโปรแกรมอีกต่างหาก ซึ่งก็ไม่รู้ว่าอะไรดลใจบริษัทหลักทรัพย์เหล่านั้น ทำให้มีการพัฒนาโปรแกรมดูหุ้นแบบใหม่ โดยใช้กลไก Java Applet ร่วมกับ Active X เพื่อให้สามารถดูหุ้นผ่าน Web Browser ได้ โดยที่ลูกค้าไม่ต้องเสียเวลามาดาวน์โหลดและติดตั้งโปรแกรมดูหุ้นอีกต่อไป

Rich Internet Application คือคำตอบ?

ปัญหาใหญ่ของ Java คือมันช้า และดูท่าทางจะไม่เหมาะกับการโต้ตอบแบบสองทาง เพราะเห็นได้ชัดว่าถ้าผมดูหุ้นผ่านโปรแกรมดูหุ้นแบบ Java Applet ที่บ้านมันจะไม่มีปัญหา สามารถสื่อสารข้อมูลแบบสองทางได้ แต่ถ้ามาดูที่ทำงานซึ่งต้องกำหนด Proxy แล้วล่ะก็ โปรแกรมดูหุ้นจะแบ๊ะ ๆ ไม่สามารถสื่อสารสองทางได้ทันที

และทางบริษัทหลักทรัพย์ก็คงจะรู้ในข้อด้อยข้อนี้ พี่แกก็เลยทำโปรแกรมรุ่นใหม่ออกมา เพื่อให้ยังคงความเป็น Web Application อยู่ แต่เพิ่มขีดความสามารถในการตอบโต้แบบสองทางเข้าไป โดยการเลือกใช้ Web Application Framework ที่สนับสนุนความเป็น Rich Internet Application ขึ้นมา เพื่อยกระดับโปรแกรมดูหุ้นให้มีความยืดหยุ่นมากยิ่งขึ้น

เสียดายที่ความเป็น Rich Internet Application บางครั้งมันก็ขึ้นกับ Platform ดังนั้น ทุกวันนี้ผมก็เลยต้องดูหุ้นผ่านโปรแกรมดูหุ้น ที่ทำงานเฉพาะบน Internet Explorer เท่านั้น (มันทำจาก ASP .NET) ยังไม่สามารถใช้งานผ่าน Web Browser อื่นอย่าง Mozilla Firefox หรือ Google Chrome

Smart Phone ของเรา

ผมยังไม่มี Smart Phone เป็นของตัวเอง ยังอาศัยจิ้มเล่นจากของผู้ร่วมงานและเพื่อน ๆ อยู่ ก็เลยยังไม่เคยซื้อขายหุ้นผ่าน Smart Phone จริง ๆ ซักที เลยยังไม่สามารถโม้ได้ว่า มันน่าจะขับเคลื่อนด้วยเทคโนโลยีอะไรบ้าง

สรุป

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

1. ยุค Desktop Application
2. ยุค Web Application
3. ยุค Mobile Application

โดยส่วนตัวแล้ว ถ้าเป็นในฐานะผู้พัฒนา Application Software ผมค่อนข้างมีพื้นฐานที่เข้มแข็งใน Desktop Application, มีพื้นฐานปานกลางใน Web Application และไร้พื้นฐานใน Mobile Application

ส่วนในฐานะผู้ใช้งาน Application Software ผมก็เหมือนชนชั้นกลางในยุคคลื่นลูกที่สามทั่วไป ที่ลองมาแล้วร้อยเอ็ดเจ็ดย่านน้ำ ไม่ว่าจะเป็น Desktop Application, Web Application หรือ Mobile Application

ประเด็นที่จะโม้มีอยู่สองเรื่อง …

เรื่องแรกผมมองว่าต่อไป สัดส่วนของนักพัฒนา Application Software ประเ้ภท Desktop Application, Web Application และ Mobile Application จะไม่เสถียร และมีแนวโน้มโอนเอียงกระจายไปยัง Web Application กับ Mobile Application มากขึ้น ในลักษณะของภาพสามเหลี่ยมด้านเท่าแบบคว่ำ

เรื่องสองผมมองว่า มูลค่าของนักพัฒนา Application Software ประเภท Desktop Application, Web Application และ Mobile Application จะมีลักษณะเหมือนกับภาพนาฬิกาทราย ด้วยสาเหตุเพราะเราจะเริ่มหาคนเก่ง Desktop Application ยากขึ้น ในขณะที่คนเก่ง Mobile Application ก็เป็นที่ต้องการตัวอย่างมาก อันเนื่องจากการขยายตัวของตลาด Mobile Application ที่กำลังจะเกิดขึ้นในอนาคต

โลกเรานี้แปลกนัก ผู้สร้างสรรค์มักมีเพียงหยิบมือ ส่วนผู้ใช้งานกลับมีมากมายก่ายกอง!!!

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

ผมล่ะชอบจริง ๆ เลยไอ้เจ้า Framework ซ้อน Framework เนี่ย ^-^