HHVM เทคโนโลยีที่ชาว Server Side ควรเริ่มศึกษาไว้ ณ บัดนาว

  

HHVM เทคโนโลยีที่ชาว Server Side ควรเริ่มศึกษาไว้ ณ บัดนาว

ก่อนอื่น ขอสลับโหมดท่านผู้อ่านก่อน เนื้อหาตอนนี้มันสัพเพเหระตั้งแต่ทำอาหารยังเขียนโปรแกรม ยังไงแปะ Rating ก่อนเลย Blog นี้ Geek นะ ! โป้ง !

ตั้งแต่ node.js เกิดมา PHP ก็หมดความเซ็กซี่ลงไปเรื่อยๆจาก Performance ที่ยังไงก็สู้ node.js ไม่ได้ ในขณะที่เว็บทุกวันนี้ก็เน้น Scalable ทุกหยด Performance นั้นถือเป็นสิ่งสำคัญ เงินทั้งนั้นนะเว้ยเฮ้ย คนก็เลยหันไปเล่น node.js กันเยอะขึ้นเรื่อยๆ เกิดหนทางการพัฒนาแตกออกมาเป็นร้อยสายกว่าหมื่นกระบวนท่า เกิดเป็น Stack ต่างๆขึ้นมาให้เลือกเพียบ เช่น MEAN, MEANJS, CompoundJS, Sails ผนวกกับ Add on ประกบหน้าประกบหลังประกบบนประกบล่างเอบีเอบีสตาร์ท นับแล้วศึกษายังไงก็ไม่หมด อ้วกพุ่งกันไปเลยทีเดียว จึงไม่ต้องแปลกที่จะได้เห็น Graph นี้จาก Github

Source: GitHub language trends and the fragmenting landscape

Javascript ครองโลกกกกก ทางด้าน PHP ตกมาหน่อยนึง สภาวะทรงตัวมาหลายปีละ ส่วน Ruby ... ดิ่งงงงง (แต่ก็ยังเยอะกว่าโปรเจค PHP อยู่ดี)

ทางด้าน PHP เห็นแบบนี้ก็คิดว่าคงไม่ดีแน่ จึงมีการพัฒนาแนวทางออกมาอยู่หลายต่อหลายอย่าง ตั้งแต่การอัพเกรด Performance ที่ตัว PHP Runtime เอง การอัพ APC หรือยัด APC Replacement อย่าง Zend OPCache รวมถึง Native Extension อย่าง PhalconPHP ที่ไปทำคำสั่งต่างๆในระดับ Native เลย

แต่สุดท้าย จนแล้วจนรอด ก็ยังไม่มีท่าไหนที่สามารถสู้ node.js ได้อยู่ดี (แต่ Phalcon นี่ใกล้ที่สุดละ ถือว่าเจ๋งไม่น้อยเลยหละ) ข้อดีข้อเดียวของมันพักหลังนี้คือเขียนง่าย หาโปรแกรมเมอร์ทำง่าย แต่ก็ Trade Off กับ Performance ที่ไม่เหมาะกับงานสเกลใหญ่

แต่แล้ว นายมาร์ค ซักเกอร์เบอร์ค ก็ขี่ม้าขาวมาช่วยมวลมนุษย์เหล่า Server Side Guy

วันนี้มีโอกาสนั่งเล่น HHVM นิดหน่อย ตอนแรกก็ไม่อะไรหรอก แต่พอได้ลองเท่านั้นแหละ ... หิวข้าวเลย ยังไม่ได้กินตั้งแต่เช้า เอาแต่ทำงาน T_T

ไม่ใช่!

พอมีโอกาสได้ลองก็ติดลม ลองหนักขึ้นเรื่อยๆลึกลงเรื่อยๆจนเห็น Potential อันยาวไกลของ HHVM ผุดขึ้นมาเป็นฉากๆเลยทีเดียว อารมณ์ว่ามันสามารถเปลี่ยนโลกได้เหมือนที่ node.js เปลี่ยนมาแล้วรอบนึง จนคิดว่ามันเป็นเรื่องสำคัญมากจนต้องมาเขียน Blog เลย (ระดับความสำคัญนี่พอๆกับไข่ออนเซ็นเลยนะ)

แต่นี่ยังศึกษาไม่นานมาก เลยขอไม่ลงลึกมากนะครับ เอาแค่คร่าวๆพอเห็นภาพก่อนละกันโนะะะะ

กำเนิด HHVM และหลักการทำงาน

จุดกำเนิดของ HHVM คือ HipHop PHP Compiler (HPHPc) ระบบอันเลื่องชื่อของ Facebook ที่คอมไพล์โค้ดภาษา PHP ออกมาเป็น Executable Binary จนทำให้ทุกอย่างทำงานเร็วมากและกิน Resource น้อยกว่าทั่วไปมาก (ก็มันเป็น Native นี่นา) จึงถูกใช้บนเว็บ facebook.com มาช้านานและช่วยประหยัดค่าใช้จ่ายของบริษัทไปได้เยอะมาก

แต่แล้ว HPHPc ถึงจะเทพปานนั้น แต่ก็มีปัญหาอยู่มากมาย หลักๆเลยคือไม่สนับสนุนภาษา PHP เต็มรูปแบบ บางคำสั่งก็ได้ บางคำสั่งก็ไม่ได้ รวมถึงคำสั่งที่ใช้บ่อยในการเขียน Advance PHP Programming ในยุคหลังอย่าง create_function, eval ก็ใช้งานไม่ได้เช่นกัน ผนวกกับปัญหาอีกมากมายก่ายกอง เช่นกิน Resource ในการคอมไพล์มาก ดีบั๊กยาก บลาๆๆๆ จนส่งผลให้ท้ายที่สุด Facebook ก็ประกาศเซย์กู้ดบายกับเจ้า HPHPc ไป

แล้ว Facebook ก็หายไปแว้บนึง โผล่มาอีกทีกับความเท่สุดบรรยาย ด้วยการเปิดตัว HHVM (HipHop Virtual Machine) ที่ทำตัวเป็น Interpreter ทำงานแทน PHP Interpreter เช่นพวก php5-fpm เลยโดยสมบูรณ์ ทำหน้าที่รับโค้ดเข้ามา แล้วแปลงเป็น Bytecode (HHBC) ก่อนจะแปลงเป็น Binary เพื่อรันแบบ Native อีกทีหนึ่งด้วย JIT ผลคือไม่ต้องมานั่งคอมไพล์ก่อนรันเพราะมันคอมไพล์แบบ Runtime ให้ แถมยังคงซึ่งประสิทธิภาพที่เหนือกว่า PHP ทั่วไปอย่างมหาศาล จากการที่มันเป็น Native และ I/O Non Blocking ล่าสุดประสิทธิภาพของมันแซง HPHPc ไปเป็นที่เรียบร้อยแล้วตั้งแต่ปีก่อน

ถ้าให้พูด Big Picture มันให้อารมณ์เหมือนเขียน node.js ด้วยภาษา PHP ยังไงอย่างงั้นเลย โดยผลไม่ใช่แค่ประสิทธิภาพการประมวลผลที่ดีขึ้น หากแต่ยังกิน Resource น้อยกว่ามากและรับ Concurrent ได้สูงกว่าหลายเท่าตัวอีกด้วย

และมันก็ถูกพัฒนาไปอย่างต่อเนื่องไม่หยุดหย่อน บั๊กทั้งหลายค่อยๆถูกกำจัดไปทีนิดๆ ฟังก์ชั่นต่างๆก็ได้รับการสนับสนุนเพิ่มขึ้นเรื่อยๆ พวก Framework ดังๆทั้งหลายก็ผ่านการเทสต์ไปเกือบหมดแล้ว เย้ ! (ลองอ่านผลการเทสต์ได้จาก http://hhvm.com/frameworks/)

ถามว่ามันจริงจังแค่ไหน? ก็ตอนนี้ Facebook ใช้ HHVM รัน facebook.com อยู่นี่แหละครับ

Hack Language

ไหนๆก็ทำ Interpreter/Runtime เองแล้ว Facebook ก็เลยใช้โอกาสนี้ สร้างโครงสร้างภาษาเพิ่มเติมจาก PHP ของตัวเองขึ้นมาพร้อมกับ Library เพิ่มเติมบางส่วน ชื่อว่า Hack Language ที่ทำให้การเขียนโปรแกรมด้วย PHP ที่ว่าง่ายแล้ว ง่ายขึ้นไปอีกและมีรูปแบบภาษาที่ Flexible น้อยลง (หรือเขียนผิดได้ยากขึ้นนั่นเอง) ทำอะไรได้อีกเพียบ ไม่ว่าจะเป็น Generic Classes/Methods (เช่น class Box<T>) พวก Collections (Vector, Set, Pair) ก็มีให้ใช้ แล้วก็ยังใช้ async await ได้ จากประโยชน์ของ I/O Non-Blocking นั่นเอง (อันสุดท้ายนี้ชอบมาก)

สำหรับ Hack Language ทาง Facebook กำลังพยายามดันอยู่อย่างเต็มที่ ลองไปอ่านเพิ่มดูกันได้ครับ ที่ http://hacklang.org/ =)

โค้ดบางส่วนยังคงใช้งานไม่ได้และใช้ Extension ร่วมกับ PHP เดิมไม่ได้

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

ส่วนเรื่อง Extension ก็อาจจะเป็นอีกปัญหานึงเพราะ HHVM ไม่ได้ใช้ Codebase เดียวกันกับ PHP เดิม ส่งผลให้ Extension ที่เขียนมาเพื่อ PHP เดิม ไม่สามารถนำมาใช้กับ HHVM ได้เลย แต่เผอิญ HHVM ก็เปิดตัวมาสักพักนึงแล้ว ทำให้เริ่มมีคน Port Extension มาให้ HHVM ใช้กันแล้ว อยู่ใน github มีเพียบเลย แต่ถามว่าครอบคลุมเท่าตัวเดิมรึยัง? ก็ต้องยอมรับว่ายังครับ

Performance ไม่ได้ดีกว่าเสมอไป

นั่งอ่าน Benchmark เยอะแยะมากมายจนตาแฉะ พบว่า HHVM ไม่ได้เร็วที่สุดในทุกกรณี โดยอ่านมาหลายเว็บแล้วผลตรงกันคือ

ถ้าโค้ดทำงานไม่หนัก Performance จะแย่กว่า Zend OPCache แต่ถ้าโค้ดทำงานหนัก HHVM จะมี Performance ที่ดีกว่า

ซึ่งถึงจะแย่กว่าแต่ก็แย่กว่าไม่มาก เรียกว่าใกล้ๆกัน โดยเว็บนี้เป็นเว็บที่เห็นผลได้ชัดที่สุด Symfony benchmark using HHVM

โค้ดไม่หนักก็เช่น Hello World ส่วนโค้ดหนักก็เช่น Fibonacci ที่ทำผล Benchmark ต่างกันกระจุยกระจายหลายสิบเท่า

ส่วนเว็บนี้เป็นอีกผลการทดลอง PHP’s HipHop outperforms PHP 5.5 with Zend OPCache and Nginx by 15-20 times โดยได้ผลได้น่าสนใจว่า HHVM สามารถรับ Request per second ได้มากกว่า OPCache ถึง 20 เท่า โดยใช้เวลาในการประมวลผลเพียง 8% ของ OPCache เท่านั้นเอง

แต่โดยเฉลี่ยแล้ว Performance ของ HHVM จะดีกว่า "อย่างมีนัยสำคัญ" เพราะโค้ดมักจะซับซ้อนเกินจุด Hello World อยู่แล้ว

แต่ความหนักของโค้ดก็ไม่ใช่ปัจจัยเดียวที่มีผลต่อ Performance ...

โครงสร้างโค้ดมีผลต่อ Performance

ผลการทดสอบของเว็บ PHP 5.5 vs HHVM vs Node.js Benchmark part 2 และ PHP 5.5 vs HHVM vs Node.js Benchmark part 3 ก็เป็นอีกอันที่น่าสนใจ

เป็นการทดสอบโค้ดเดิม โดยอันนึง Wrap อยู่ใน function ส่วนอีกอันรันออกมาข้างนอก ผลการทดลองออกมาคือ ในเคสที่ไม่ได้ Wrap ใน function ผล Response Time ออกมาแย่ในระดับเลวร้าย แย่กว่า php5.5 ถึง 5 เท่า และแย่กว่า node.js ถึง 36 เท่า แต่ เคสที่ Wrap โค้ดอยู่ใน function ประสิทธิภาพกลับดีขึ้นทันที 40 เท่า และเทียบประสิทธิภาพได้เท่ากับ node.js เลย

จะเห็นได้ว่าแค่เขียนโค้ดต่างกัน ผลการทำงานก็ประสิทธิภาพต่างกันแล้ว อันนี้ต้องเรียนรู้ Best Practise และเข้าใจตัว Interpreter ว่ามันคอมไพล์โค้ดเป็น Bytecode อย่างไร

ไม่รู้ว่าตรงนี้ทางทีม HHVM แก้ไขหรือยัง ถ้าแก้ไขแล้วก็อาจจะสบายหน่อย แต่ถ้ายังก็คงต้องเรียนรู้เพิ่มเติมครับ

ถึงเวลาสลับไปใช้ HHVM หรือยัง?

HHVM มีการใช้งานจริงแล้วในหลายพื้นที่ รวมถึง Facebook แต่อย่างที่บอกว่า HHVM มันยังแทนที่ PHP ตัวเดิมไม่ได้แบบ 100% ดังนั้นมีหลายปัจจัยมากที่ต้องพิจารณาก่อนจะสลับไปใช้ HHVM อย่างจริงจัง เช่น

1) โค้ดสนับสนุน 100% หรือไม่ (อันนี้สำคัญมาก)

2) Performance ดีขึ้นหรือไม่ (จากเหตุผลด้านบน โค้ดต่าง ประสิทธิภาพต่าง)

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

Segmentation Fault

เมี่ยงเอ้ย ตามมาหลอกหลอนอีกละ - -

ตอนนี้ http://nuuneoi.com  http://nichieme.com (Wordpress) ก็สลับมาใช้ HHVM เป็นที่เรียบร้อยแล้วครับ ใช้ทุกอย่างได้สมบูรณ์ดี ไม่ต้องเปลี่ยนโค้ดเลย และก็เป็นไปตามที่เค้าโม้เลย มันเร็วขึ้นและกิน Resource น้อยลงจริงๆ

ทำไม HHVM ถึงสำคัญและคนทำด้าน Server Side ควรจะศึกษาไว้ตั้งแต่ตอนนี้?

เราสลับไปใช้ node.js ก็เพราะประสิทธิภาพที่ดีขึ้น มัน Solve Pain ของ Server Side Programmer เรื่องของประสิทธิภาพได้เป็นอย่างดี แต่ก็ต้องแลกกับการมานั่งปวดหัวและ Handle Error ต่างๆนานา เกิดเป็น Pain ใหม่ขึ้นมา

แต่พอ HHVM เกิดขึ้นมา มัน Solve Pain ครบเลย ทั้งเรื่องประสิทธิภาพและเรื่องความง่ายของภาษา ไม่ต้องมานั่งปวดหัวเรื่องการ Handle Error หรือเรื่อง Server จะล่มมั้ยอีกต่อไป ตอบโจทย์ครบทุกอย่างที่ Server Side Programming แบบเน้นประสิทธิภาพต้องการแล้ว ตอนนี้ถ้าจะขาดก็แค่เรื่องของ Extension เท่านั้นเอง (ซึ่ง Community ก็ขยันปั่นออกมาอย่างไม่หยุดยั้งตอนนี้ ใครอยากร่วมด้วยช่วยปั่น ลองดู Extension API ได้)

หลังจากได้เล่นและทดสอบแล้ว ส่วนตัวเชื่อว่า HHVM จะเป็น Base ของการพัฒนา Framework ในสาย PHP ต่อจากนี้อีกยาวไกล จะมี Extension ออกมามากมาย จะมีเป็น Dependency เพื่อ Install อัตโนมัติเหมือนพวก bower อะไรออกมา โดยประสิทธิภาพสามารถฟาดฟันกับ node.js ได้อย่างสบายๆ ด้วยพลังการเขียนที่น้อยกว่ามาก

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

ดังนั้น จับไว้ครับ

โลกหมุนไว ลูกต้องก้าวให้ทัน

แต่ก่อน PHP ฮิตมาก ไปๆมาๆ node.js ตอนนี้ฮิตมาก (แต่ก็หาโปรแกรมเมอร์ทำได้ยากเหลือเกิน) แล้วตอนนี้ PHP ก็กำลังจะกลับมามีบทบาทเพิ่มอีกแล้ว

วันก่อนมีคนมาถามว่า "จะจับเทคโนโลยีไหนดี มันไปไวเหลือเกิน" ก็คงต้องขอตอบว่า อย่ายึดติดกับสิ่งใด โลกนี้มันหมุนไวมาก สิ่งที่เกิดมาตอนนี้แล้วช่างหรูหราฟู่ฟ่า มันอาจจะกลายเป็นสิ่งไร้ค่าในอีก 3 เดือนข้างหน้าก็เป็นได้ ดังนั้น ... Fast Adopter wins ครับ

DONE is better than PERFECT

และมีคนถามอีกว่าจะใช้ node.js หรือ PHP หรือจะไป django หรือจะ RoR ดีครับ

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

แล้วมันจะมีประโยชน์อะไรที่ทำไม่เสร็จและงานไม่ได้ Launch?

DONE is better than PERFECT

จับที่ตัวเองถนัดและลุยมันให้เสร็จเป็นสิ่งที่สำคัญที่สุด จากนั้นค่อยพัฒนาตัวเองและทำให้มันดีขึ้นหรือจะเขียนใหม่ก็ว่ากันอีกที ก็ต้อง Balance ด้วยเน้อ ^_^

Reference:

- Symfony benchmark using HHVM

- PHP 5.5 vs HHVM vs Node.js Benchmark

- PHP 5.5 vs HHVM vs Node.js Benchmark part 2

- PHP 5.5 vs HHVM vs Node.js Benchmark part 3

- PHP’s HipHop outperforms PHP 5.5 with Zend OPCache and Nginx by 15-20 times

- HHVM with Symfony 2 looks amazing

- HHVM, Nginx and Laravel

ที่มา:https://nuuneoi.com/blog/blog.php?read_id=671

มาดูเหตุผลของการนำ PHP มาใช้งาน

มาดูเหตุผลของการนำ PHP มาใช้งาน
โดยไม่สนใจว่าตัวภาษามันจะแย่ก็ตามเถอะนะ

1. PHP มันเรียบง่าย ไม่เยอะ

สามารถเริ่มต้นพัฒนาได้ง่าย ในทุกๆ ระบบปฏิบัติการ
นักพัฒนาใหม่ๆ สามารถเริ่มต้นศึกษาง่ายสุดๆ

2. PHP มีประสิทธิภาพในการทำงาน

มีชุดของ library พื้นฐานที่มีประสิทธิภาพจำนวนมาก
ซึ่งมันมาพร้อมกับตัวภาษา PHP เลย ไม่ต้องไปตามหาให้ยาก
เช่น

• ถ้าคุณต้องการติดต่อ database ก็มีให้
• ถ้าคุณต้องการจัดการรูปภาพ ก็มีให้
• ถ้าคุณต้องการคำนวณข้อมูลตัวเลย ก็มีให้

3. มีเอกสารที่ดีมากๆ

PHP document คือสิ่งที่ดีมากๆ
ซึ่งนักพัฒนาทุกคนต้องมีไว้ประจำเครื่องเสมอ
มันจะอธิบายทุกๆ library, function ที่คุณต้องการใช้งาน

4. มันทำงานเร็วนะ

หมายถึงเวลาในการพัฒนานะครับ
ไม่ใช่ความเร็วที่เกิดจากการปรับปแต่งประสิทธิภาพการทำงาน เช่น HHVM, HACK

คุณสามารถพัฒนาระบบต่างๆ ขึ้นมาได้อย่างรวดเร็ว
รอบการทำงาน คือ coding + testing + fixing + coding ที่รวดเร็วมากๆ

5. ไม่ได้กำหนดว่าคนจะเขียนโปรแกรมในรูปแบบไหน

อยากจะพัฒนาด้วยแนวทาง Object-Oriented Programming ได้ไหม ? ตอบว่าได้
อยากจะพัฒนาด้วยแนวทาง Procedural Programming ได้ไหม ? ตอบว่าได้
อยากจะพัฒนาด้วยแนวทาง Functional Programming ได้ไหม ? ตอบว่าได้
อยากใช้รวมกันได้ไหม ? ตอบว่าได้

6. มันมีอนาคตที่น่าสนใจมากๆ

สามารถเข้าไปดู roadmap ของ PHP ได้จากที่ RFCs
ยิ่งทางฝั่ง facebook ก็ได้สร้าง Hack ขึ้นมา ซึ่งเป็นการเพิ่มประสิทธิภาพการทำงานของ PHP ให้สูงขึ้น
รวมทั้งเพิ่มความสามารถใหม่ๆ เข้ามา โดยที่รูปแบบการเขียนยังคงเป็นเช่นเดิม
รวมทั้งยังทำการเพิ่มความสามารถใหม่ๆ เข้ามายัง PHP อยู่อย่างเสมอ

และนี่คือเหตุผลของผม สำหรับการนำ PHP มาพัฒนาระบบ Web application
แล้วของคุณล่ะ เป็นอย่างไรกันบ้าง ?

ปล. สำหรับประเทศไทย ยังคงใช้ PHP เป็นภาษาหลักในการพัฒนาระบบ Web application นะ
ปล. ส่วนตัวคิดว่า คนที่นำไปใช้งาน คงต้องส่องกระจกดูตัวเองด้วยนะ ว่านำไปใช้งานอย่างถูกต้องหรือไม่

 ที่มา :http://www.somkiat.cc/why-i-like-php/

Gartner เผย 3 เทรนด์เทคโนโลยี ที่จะส่งผลกระทบต่อทั้งโลกไปอีก 10 ปี

Gartner ได้ออกมาวิเคราะห์ถึงเทคโนโลยี 3 กลุ่มหลักๆ จากเทคโนโลยีใหม่ๆ ทั้งสิ้น 2,000 รายการ ที่จะส่งผลกระทบต่อภาคธุรกิจทั่วโลกในการก้าวไปสู่การเป็น Digital Business ในอีก 10 ปีนับถัดจากนี้

Credit: Gartner

การวิเคราะห์แนวโน้มครั้งนี้เป็นการวิเคราะห์ต่อยอดขึ้นมาจาก Hype Cycle for Emerging Technologies 2017 ที่ได้ทำการวิเคราะห์ถึงเทคโนโลยีที่กำลังเป็นที่สนใจของภาคธุรกิจในปี 2017 นี้ และจัดกลุ่มออกมาด้วยกันได้ 3 กลุ่ม ได้แก่

1. AI Everywhere

Gartner ได้ยกให้ Artificial Intelligence (AI) เป็นเทคโนโลยีที่จะเข้ามาเปลี่ยนแปลงภาคธุรกิจมากที่สุดในอีก 10 ปีนับถัดจากนี้ ด้วยการพัฒนาอย่างรวดเร็วของเทคโนโลยีด้านการประมวลผล, ปริมาณข้อมูลที่เพิ่มขึ้นอย่างไร้ขีดจำกัด, ความก้าวหน้าแบบก้าวกระโดดของเทคโนโลยี Deep Neural Networks ซึ่งทั้งหมดนี้จะทำให้องค์กรสามารถนำ AI ไปใช้งานได้อย่างมีประสิทธิภาพมากยิ่งขึ้นด้วยการประยุกต์นำข้อมูลต่างๆ มาใช้สร้างสรรค์สิ่งใหม่ๆ และแก้ปัญหาใหม่ๆ ที่ยังไม่เคยเจอมาก่อนกันได้อย่างรวดเร็วยิ่งขึ้น

เทคโนโลยีที่ Gartner แนะนำให้องค์กรเริ่มศึกษานั้นได้แก่ Deep Learning, Deep Reinforcement Learning, Artificial General Intelligence, Autonomous Vehicles, Cognitive Computing, Commercial UAVs (Drones), Conversational User Interfaces, Enterprise Taxonomy and Ontology Management, Machine Learning, Smart Dust, Smart Robots และ Smart Workspace

2. Transparently Immersive Experiences

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

เทคโนโลยีที่ Gartner แนะนำให้องค์กรเริ่มศึกษานั้นได้แก่ 4D Printing, Augmented Reality (AR), Computer-Brain Interface, Connected Home, Human Augmentation, Nanotube Electronics, Virtual Reality (VR) และ Volumetric Displays

3. Digital Platforms

Gartner ทำนายว่าเทคโนโลยีที่เกิดขึ้นใหม่นี้จะต้องการเทคโนโลยีพื้นฐานใหม่ๆ ที่ช่วยสร้างหรือรวบรวมข้อมูลตามที่เทคโนโลยีอื่นๆ ต้องการนำไปใช้, มีความสามารถในการประมวลผลระดับสูง และสามารถนำไปใช้งานได้อย่างกว้างขวางในหลากหลายสถานการณ์ เข้าสู่การเป็น Ecosystem-enabling Platform และเกิดเป็น Business Model รูปแบบใหม่ๆ ที่สร้างการเชื่อมต่อระหว่างมนุษย์และเทคโนโลยีขึ้น

เทคโนโลยีที่ Gartner แนะนำให้องค์กรเริ่มศึกษานั้นได้แก่ 5G, Digital Twin, Edge Computing, Blockchain, IoT Platform, Neuromorphic Hardware, Quantum Computing, Serverless PaaS และ Software-Defined Security

สุดท้าย Gartner ยังได้สรุปว่า AI Everywhere นั้นเป็นแนวโน้มที่จะเติบโตอย่างรวดเร็วมาก โดยอาศัยเทคโนโลยีจากกลุ่ม Transparently Immersive Experiences เป็นพื้นฐานสำหรับการต่อยอด และ Digital Platforms เองก็จะเป็นอีกกลุ่มที่เติบโตตามมา

ไม่สามารถ start apache บน Xampp

จะขึ้น Error สีแดงๆตามรูป error จะแตกต่างกันไปแล้วแต่เครื่อง

สาเหตุหลักๆ ของการเกิด error เนื่องจาก port 80 ถูกโปรแกรมอื่นใช้งานอยู่
บางทีก็ขึ้นแบบนี้ Port 80 in use by “Unable to open process” with PID 4!
เช่น โปรแกรม skype หรือ World Wide Web Publishing Service
ทางแก้หลักๆมีอยู่สองทาง
1 ปิดโปรแกรมที่ใช้งาน port 80
2 เลี่ยงไปใช้ portอื่น แทน port 80

ปิดโปรแกรมที่ใช้งาน port 80

ปิดโปรแกรม skype หรือปิด World Wide Web Publishing Service
การปิด World Wide Web Publishing Service เข้าไปที้ control panel > administrative tools > serviecs
มองหา World Wide Web Publishing Service แล้วกด stop หรือ disable มันซะ
เมื่อปิดแล้ว ก็ลองstart apache ดูอีกครั้ง

การเลี่ยงไปใช้ portอื่น แทน port 80

ไปที่ config > Apcche (httpd.conf)

มองหาบรรทัด Listen 80
เปลี่ยนเป็น Listen 8080

มองหาบรรทัด ServerName localhost:80
เปลี่ยนเป็น ServerName localhost:8080
เมื่อเปลียนครบสองที่แล้วให้กด save


ยังไม่จบต้องไปเปลี่ยน ค่าservice port ให้ Xampp ก่อน
ไปที่config ที่เป็นรูปประแจ

เลือก Serviec and port port settings

ที่แท๊ปApache > Main Port เปลี่ยนเป็น 8080
หากจะเปลี่ยน SSL port เป็น port อื่นก็เปลี่ยนได้
แต่ต้องตามไปแก้ไฟล์ config > Apache (httpd-ssl.conf)
ให้เป็น port 444 ด้วย
กด Save แล้ว ก็ กด Save อีกครั้ง

จากนั้นลอง start apache ถ้าแก้ไขถูกต้อง ก็จะขึ้นตามรูป


ทิ้งท้ายด้วย การแก้ไขไฟล์ Apache (httpd-ssl.conf)

เรียกใช้งานก็ localhost:8080

 ที่มา:http://mistercheckman.com