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

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

ก็ประชุมกันไปครับ เอาคนที่ทำด้านเครือข่าย เครื่องแม่ข่าย โปรแกรมคอมพิวเตอร์ และ ความมั่นคงปลอดภัย มานั่งคุยกัน คุยกันตั้งนานกว่าจะเข้าใจวิธีการทำงาน เพราะพวกเขาคิดว่า ต่างฝ่ายต่างรู้เรื่อง Push Technology กับ Pull Technology กัน เลยไม่ได้อธิบายให้ชัดว่าจะเลือกใช้วิธีไหนกัน

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

Push Technology กับ Pull Technology เป็นเรื่องง่าย ๆ ด้านการสื่อสารข้อมูลผ่านเครือข่ายภายใน เครือข่ายภายนอก หรือเครือข่ายอินเทอร์เน็ตครับ ไม่สนว่าจะใช้โปรโตคอลอะไรเลยก็ยังได้ ขอแค่ปฏิบัติประมาณนี้ก็เรียกว่า Push Technology หรือ Pull Technology แล้ว

เริ่มแรก มาดูภาพที่ผมพยายามอธิบายเกี่ยวกับ Push Technology กันดีกว่า ผมไม่เขียนเยอะนะ ดูหลักการเอาจากรูปแล้วกันครับ

จากภาพข้างบนจะเห็นว่า หลักการ Push Technology คือ ถ้ามองตัวเราเป็น Server เราก็จะมีบทสนทนากับ Client ประมาณว่า

“เธอต่อเข้ามาหาฉันนะ แล้วเธอก็รับโน่นรับนี่จากฉันไปแล้วกัน อย่าบ่นล่ะ รับไปเฉย ๆ นิ่ง ๆ เธอไม่ต้องขอ ฉันให้เธอเอง”

ในขณะที่ถ้าเป็น Pull Technology จะเป็นยังไง โดยปรกติมันจะเป็นแบบภาพข้างล่างนี้ครับ ไม่อธิบายเยอะนะ ลองดูจากภาพเอา

ถ้าให้อธิบายภาพข้างบนของ Pull Technology เป็นบทสนทนา โดยมองว่าตัวเราเป็น Server แล้วคุยกับ Client ก็จะมีบทสนทนาประมาณว่า

“เธอต่อเข้ามาหาฉันนะ จากนั้นเธอก็บอกมาว่าเธอจะเอาอะไร แล้วถ้าฉันให้ได้ฉันก็ให้เธอเองแหล่ะ แต่ถ้าเธอไม่บอก ฉันก็จะเฉย ๆ นะ ถึงฉันคิดว่ามีสิ่งที่เธอต้องการ ฉันก็ไม่ส่งให้เธอหรอก”

ทีนี้ แบบข้างบนมันเป็น Pull Technology สองทิศทาง มันมีอีกแบบหนึ่งเป็นแบบทิศทางเดียว แบบข้างล่างนี้

ถ้าอธิบายเป็นบทสนทนาสำหรับ Pull Technology ทิศทางเดียวตามภาพข้างบน โดยมองว่าตัวเราเป็น Server บทสนทนาก็จะประมาณว่า

“เธอต่อเข้ามาหาฉันนะ จากนั้นมีอะไรก็ว่ามา ฉันจะฟังเฉย ๆ อย่างเดียว”

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

ทีนี้เพื่อให้เข้าใจง่ายขึ้นอีกนิดนึง ผมจึงได้ทำตารางเปรียบเทียบครับ จะได้เห็นว่า Push / Pull Technology มันเป็นเบื้องหลังของโปรแกรมคอมพิวเตอร์แบบไหนบ้าง

จุดสำคัญอีกอย่างหนึ่งที่ผมพบเวลาคุยเรื่อง Push กับ Pull ก็คือ ไม่ค่อยมีใครบอกชัด ๆ ครับว่าใครเป็น Server และใครเป็น Client

อย่าเข้าใจว่า Server คือเครื่องใหญ่ และ Client คือเครื่องเล็กนะครับ สำหรับ Push กับ Pull ไม่จำเป็นที่ Server ต้องเป็นเครื่องใหญ่ และ Client ต้องเป็นเครื่องเล็กเสมอไป

ดังนั้น ก่อนตกลงเรื่อง Push กับ Pull ต้องตกลงกันก่อนเรื่อง Server กับ Client ให้เรียบร้อยครับ คุยผิดนี่ออกทะเลกันเลยทีเดียว

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

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

พอผ่านไปซักพักนึงผมก็เปลี่ยนยุคเป็น Broadband แบบข้าแบ่งหลายคนแบบไร้สาย โดยผมยอมซื้อ Wireless ADSL Modem Router เพื่อรับสัญญาณอินเทอร์เน็ตเข้ามา แล้วปล่อยสัญญาณอินเทอร์เน็ตให้คนทั้งบ้านแบบไร้สาย ซึ่งว่าตามจริงแล้วผมก้าวกระโดดไปหน่อย เพราะผมไม่ได้ผ่านยุค Broadband แบบข้าแบ่งหลายคนแบบมีสายไป แบบว่ากว่าผมจะรู้จัก ADSL Modem Router ตลาดบ้านเราก็ใช้เทคโนโลยีไร้สายกันหมดแล้ว ผมก็เลยไม่ต้องมาใช้เทคโนโลยีลากสาย LAN ให้มันยุ่งยากอีก

บ้านเก่าก็ปล่อยให้มันเป็นแบบนั้นไป ส่วนที่บ้านใหม่ผมมีทางเลือกใหม่ ๆ สามทาง นอกเหนือจากแบบเดิม ๆ ในการเข้าใช้อินเทอร์เน็ต ซึ่งวิธีแรกคือ AIS AIRNET, วิธีที่สองคือ AIS AirCard และวิธีที่สามคือ True Wifi

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

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

สุดท้ายเป็น True Wifi ผมตรวจแล้วจุด Hotspots มันอยู่ไกลบ้านใหม่ผมพอควร ผมยังไม่ได้ไปตรวจว่าสัญญาณไม่ถึง หรือสัญญาณมันถึงแต่ว่าอ่อนหรือเปล่า แต่ยังไงก็ต้องอธิบายหน่อยว่าบริการนี้ถือว่าดีมาก หากเราจะใช้บริการอินเทอร์เน็ตแบบติดพื้นที่ ไม่เคลื่อนย้ายไปไหนไกล ๆ แถมเราไม่ต้องลงทุนซื้อ ADSL Modem Router, ไม่ต้องลากสายอินเทอร์เน็ตเข้าบ้านกรณีจะใช้ Broadband แบบเดิม, ไม่ต้องตั้งตัวรับสัญญาณอินเทอร์เน็ตแบบ AIS Aircard ในกรณีที่เราจะใช้บริการแบบไร้สาย และผมก็ใช้อินเทอร์เน็ตอยู่คนเดียว ไอ้แบบนี้แหล่ะที่จะใช้ต้นทุนน้อยที่สุด เพราะเครื่องผมเป็นภาครับแต่เพียงอย่างเดียว

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

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

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 แล้วล่ะก็ อย่าลืมหาตังค์มาเลี้ยงมันด้วยเน้อ

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

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

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

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

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

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. ทำงานอยู่ที่ทำงาน และ งานอยู่ที่ทำงาน

แบบนี้ธรรมดา เป็นกันเกือบจะทุกที่อยู่แล้ว

2. ทำงานอยู่ที่พักอาศัย และ งานอยู่ที่พักอาศัย

ถ้าแบบนี้แยกได้เป็นสองพวก คือ พวก Freelance กับพวกชีวิตน่าสงสาร เพราะต้องเอางานจากที่ทำงานมาทำที่บ้าน!!!

3. ทำงานอยู่ที่พักอาศัย และ งานอยู่ที่ทำงาน

แบบนี้ผมเห็นได้รับความนิยมมากในช่วงที่เกิดการจราจล, รัฐประหาร, สงครามกลางเมือง, ภัยธรรมชาติ หรือ ยามวิกาล โดยการใช้ระบบคอมพิวเตอร์เครือข่ายทุกรูปแบบเข้ามาช่วย ไม่ว่าจะเป็น Virtual Private Network, Web Application, Web Service หรือ Virtual Office เพื่อทำให้เราสามารถเข้าถึง “งาน” ได้อย่างรวดเร็วที่สุด

4. ทำงานอยู่ที่ทำงาน และ งานอยู่ที่พักอาศัย

พอดีผู้ร่วมงานเล่าให้ผมฟังครับ ผมเห็นว่าน่าสนใจดี คือ เขาตั้งคอมพิวเตอร์ไว้ที่บ้าน ทำเป็น Application Server จากนั้นก็ไปสมัคร DNS เอาไว้ แล้วเอา DNS มากำหนดไว้กับ ADSL Modem Router แล้วก็ต้องมีการทำ Port Forwarding ด้วยนะ เพื่อทำให้ Application Server ของเขาออกสู่โลกภายนอกได้

ผมถามเขาว่าไม่กลัวว่า Application Server จะถูกโจมตีเหรอ? เขาตอบว่าไม่กลัว เพราะเขามีวิธีในการป้องกันอันประกอบไปด้วย การติดตั้ง Firewall ไว้ที่ ADSL Router, การทำ Disk Clone ทุกครั้งที่ Boot เครื่อง และ การไม่ต่อ Application Server เข้ากับเครือข่ายภายใน

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

กลายเป็นว่า ถ้าทำงานอยู่ที่ทำงาน และ งานอยู่ที่พักอาศัย มันก็คือ งานอดิเรก ดี ๆ นี่เอง

[tags]งาน, ที่ทำงาน, remote, server[/tags]

ผลปรากฎว่าเพื่อนผมเขาไม่เอาด้วย เขาบอกว่ามันยาก เพราะเขาไม่สามารถคำนวณวงจรให้มีขนาดเล็กกะทัดรัดได้ เขาบอกว่าวงจรไฟฟ้าที่ดีจะต้องกินไฟฟ้าน้อยและเล็กกะทัดรัด (คงเหมือนกับการเขียนโปรแกรมที่ดี ที่จะต้องสั้นที่สุดแต่มีพลานุภาพมากที่สุด)

ดังนั้น จินตนาการอันนี้ก็เลยตกไป!!!

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

ก็เลยเกิดจินตนาการขึ้นมาใหม่ตามภาพข้างล่างนี้

จากภาพข้างบนจะเห็นว่า เราสามารถควบคุมหุ่นยนต์สังเกตการณ์ของเราได้ 3 ทิศทาง อันได้แก่

1. ผ่านทางระบบ LAN โดยใช้ Wireless Router เป็นตัวสื่อสารระหว่างหุ่นยนต์กับคอมพิวเตอร์ของเรา
2. ผ่านทางระบบอินเทอร์เน็ต โดยให้ “ผู้ให้บริการหุ่นยนต์” เป็นตัวกลางเพื่อบริหารจัดการหุ่นยนต์ให้กับเรา
3. ผ่านทางระบบสัญญาณโทรศัพท์มือถือ โดยใช้ Air Card ซึ่งเสียบ SIM ของบริษัทสัมปทานสัญญาณมือถือต่าง ๆ (ในประเทศไทย) เพื่อเอาไว้ต่อเชื่อมกับหุ่นยนต์ของเรา

ไม่แน่ใจว่าแบบที่ 2 หรือแบบที่ 3 ที่จะต้องใช้เทคโนโลยีในการจัดสร้างยุ่งยากกว่ากัน???

แต่ที่รู้แน่ ๆ ก็คืิอ ขอให้มันจริง ๆ เถอะเจ้าประคู้น เพี้ยง ๆ

[tags]หุ่นยนต์, ไร้สาย[/tags]

ดาวน์โหลดไฟล์ = เอาไฟล์คอมพิวเตอร์มา แล้วเก็บไว้กับสื่อบันทึกของตัวเอง (ถ้าเอามาแล้วไม่บันทึก อันนั้นเรียกว่า สตรีมมิ่ง)

การดาวน์โหลดไฟล์มีรูปแบบใหญ่ ๆ อยู่ 2 แบบ คือ

1. ดาวน์โหลดจากศูนย์กลาง

และ …

2. ดาวน์โหลดจากใครก็ได้ (ที่เต็มใจให้ดาวน์โหลด)

แต่ถ้าจะให้ดีที่สุดนะ (ถ้าทำได้) ควรจะเป็น …

3. ดาวน์โหลดจากตัวเอง

อือม กำลังหาอยู่ ว่าแบบที่ 3 นี่ มันมีทฤษฎีทางคอมพิวเตอร์อะไรมารองรับได้บ้าง???

[tags]ดาวน์โหลด, ศูนย์กลาง, ใครก็ได้, ตัวเอง[/tags]

โดยส่วนตัวแล้วผมมีความรู้เกี่ยวกับ Smartphone น้อยมาก เพราะไม่มีเพื่อน ๆ หรือผู้ร่วมงานคนไหนครอบครอง Smartphone!!!

(ภาพจาก Wikipedia จ้า)

แต่หลังจากค้นคว้าเองเล็ก ๆ น้อย ๆ ก็ทำให้รู้ว่า มันเป็นโทรศัพท์มือถือฉลาดโคตร ๆ ที่พยายามทำตัวให้ได้เหมือนกับ PC ซึ่งบางตัวเจ๋งเป้งถึงขนาดมีระบบปฏิบัติการเทพ ๆ บนตัวมันเองอีกต่างหาก!!!

งั้นในเมื่อมันมีระบบปฏิบัติการในตัวเอง แถมมันเป็นอุปกรณ์ไร้สายอีกต่างหาก … งั้น … มันก็ควรจะทำตัวให้ได้เหมือนกับ Wireless Router, Wireless ADSL Router หรือแม้กระทั่งเป็น Web Server ได้อ่ะดิ????

แล้วถ้ามันทำตัวเป็น Web Server ได้จริง เราก็น่าจะทำ Web Service บนตัวมัน เพื่อให้มันนำส่ง Software as a Service กระจายไปยัง PC ที่ต่อเชื่อมกับมันผ่าน HTTP ได้สินะ อือม น่าสนใจ เพราะโดยทางเทคนิคแล้วมันเป็นไปได้!!!

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

[tags]Smartphone, Web Server, Wireless Router, Wireless ADSL Router, HTTP[/tags]

ถ้าคิดว่าเป็นเรื่องส่วนตัวก็คงไม่แล้วล่ะมั๊ง? เพราะเห็นเดี๋ยวนี้เรื่องราวส่วนตัวหรือไม่ส่วนตัวก็เอามาเล่าสู่กัน, รูปถ่ายไปเที่ยวหรือไปกินก็แบ่งให้ดูกัน แถมสองสามปีนี้ก้าวหน้า มีการอัดวีดีโอแจกจ่ายให้ชมกันอีกต่างหาก!!!

งั้นประวัติการเข้าเว็บไซต์ก็น่าจะถูกยกระดับให้กลายเป็นสิ่งที่แบ่งปันได้แล้วอ่ะดิ???

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

1. ทุกคนล้วนเข้าเยี่ยมชมเว็บไซต์ผ่านทาง Web Browser ไม่ยี่ห้อใดก็ยี่ห้อนึง
2. มีน้อยคนนัก (แต่ก็พอควร) ที่จะเยี่ยมชมเว็บไซต์โดยผ่าน RSS Feed

โอเค ทีนี้เราก็ได้จุดที่น่าสนใจมาอย่างนึงในข้อที่ 1 นั่นก็คือ ใคร ๆ ก็ใช้ Web Browser เพื่อเข้าเว็บไซต์ และโดยปรกติประวัติการเข้าเว็บไซต์ก็จะถูกบันทึกเอาไว้ในเครื่องโดย Web Browser ที่เราใช้อยู่นั่นแหล่ะ ซึ่งเราก็คงมีวิธีการแบ่งปันหรือจัดเก็บประวัติการเข้าเว็บไซต์ไว้บนอินเทอร์เน็ตอยู่แค่ 2 วิธี คือถ้าไม่บันทึกลงบล็อกหรือเว็บไซต์ด้วยมือ (ผ่านการ import/export) ก็คงต้องใช้คอมพิวเตอร์เป็นตัวจัดการให้บันทึกแบบอัตโนมัติให้!!!

ทุกวันนี้การบันทึกข้อมูลแล้ว ping ไปหาชาวบ้าน เพื่อให้ชาวบ้านรู้ว่ามีการปรับปรุงเนื้อหา ไม่ว่าจะเป็นการเขียนบล็อกหรือไมโครบล็อกก็ล้วนมีกันแล้วทั้งนั้น แต่นั่นเป็นการกระทำผ่าน Web Application ซึ่งเป็น script ที่ทำงานอยู่ที่ Web Server

หรือ Client Application ที่ทำงานอยู่บน Device ต่าง ๆ ที่ใช้ … แต่ไม่ใช่ผ่าน Web Browser อือม หมายถึงให้ Web Browser เป็นตัว ping ไปหาชาวบ้านน่ะ!!!

บังเอิญเราไม่สามารถไปเปลี่ยนกลไกซึ่งเป็นแกนหลักของ Web Browser ได้ ดังนั้นถ้าอยากจะทำ ก็ต้องทำผ่าน Add On แทน!!!

ดังนั้นถ้าอยากจะทำ ก็ต้องแบ่งงานออกเป็น 2 ส่วน โดยส่วนแรกเป็นการทำ Add On เพื่อแปะเข้ากับ Web Browser ต่าง ๆ, ส่วนหลังเป็นการทำ Web Service เพื่อรองรับการ ping จาก Add On ในส่วนแรก!!!

เข้าใจว่าประเด็นของซอฟต์แวร์คงไม่เท่าไหร่ … จุดที่น่าห่วงคงเป็นส่วนของฮาร์ดแวร์มากกว่า เพราะการต้องเก็บประวัติการเข้าเว็บไซต์ (แบบออนไลน์) จากบรรดาสมาชิกซึ่งสมัครใช้บริการ โดยที่แต่ล่ะรายมีความถี่ในการ ping หา Web Service ที่แตกต่างกันนั้น มันน่าจะสาหัสมากกว่าความถี่ในการ ping ที่เกิดจากการปรับปรุงบล็อกหรือไมโครบล็อกเป็นเท่าทวีคูณเลยทีเดียว

เหนือสิ่งอื่นใด … จะมีใครทำจริง ๆ หรือเปล่า สำหรับบริการแบบนี้ แล้วมันจะคุ้มหรือเปล่าเนี่ย???

[tags]ประวัติ, การเข้า, เว็บไซต์, มหาชน[/tags]