เริ่มต้นกับ Bot Framework

ตั้งแต่ต้นปีที่ผ่านมาเราก็เห็นว่า ขาใหญ่ในวงการทั้งหลายพยายามโปรโมท API ที่เรียกว่า Bot ทั้ง Facebook Google, Microsoft, Apple, LINE ต่างเปิดตัวกันครบหมด ซึ่งน่าจะเป็นสัญญาณว่า นี่คือเทรนต่อไปของ  API

ส่วนตัวผมก็อยากลองเล่นมาตั้งแต่ Microsoft เปิดตัวแล้ว จนได้มีโอกาสมาลองวันนี้ครับ

Bot Framework คืออะไร ถ้าไปดูใน  https://dev.botframework.com/ ก็คือมันก็คือระบบตอบรับอัตโนมัตินั่นเอง ซึ่งจริงๆแล้ว Bot มีมานานแล้วแต่อาจจะใช้ในงานเฉพาะทาง แต่ตอนนี้พวกบริษัทยักษ์ใหญ่ก็ทำเป็น Framework ให้เราพัฒนา Bot เพื่อใช้ใน App ของเราได้ง่ายขึ้น

เนื่องจาก Bot Framework ของ Microsoft นั้นจริงๆแล้วก็คือ Framework ที่พัฒนาต่อยอดจากแนวคิดของ Web Service ดังน้ันมันก็คือการเขียน Web Service นั่นเอง

ซึ่งเรามีตัวเลือก 2 ทางครับ
1. ใช้ Node.js
2. ใช้.NET

ครั้งนี้ผมจะใช้ Node.js ในการสร้าง Bot Service ครับ เริ่มจากสร้าง Folder เปล่า แล้วสร้าง Node.js config ด้วย command นี้

npm init

จากนั้นเราจะทำการโหลด Dependencies ที่ใช้ในการพัฒนา Bot กันครับ ด้วย command

npm install --save botbuilder
npm install --save restify

จากนั้นลองสร้างไฟล์ app.js แล้ว Copy ตามนี้

var restify = require('restify');
var builder = require('botbuilder');

//=========================================================
// Bot Setup
//=========================================================

// Setup Restify Server
var server = restify.createServer();
server.listen(process.env.port || process.env.PORT || 3978, function () {
   console.log('%s listening to %s', server.name, server.url); 
});
  
// Create chat bot
var connector = new builder.ChatConnector({
    appId: process.env.MICROSOFT_APP_ID,
    appPassword: process.env.MICROSOFT_APP_PASSWORD
});
var bot = new builder.UniversalBot(connector);
server.post('/api/messages', connector.listen());

//=========================================================
// Bots Dialogs
//=========================================================

bot.dialog('/', function (session) {
    session.send("Hello World");
});

ในส่วนของ Code ข้างบนที่เป็น JavaScript นั้นแบ่งออกได้เป็น 4 ส่วน

  1. สีแดง – การเรียกใช้งาน modules ที่เกี่ยวข้อง
  2. สีเขียว – เป็นการสร้าง Web Service แบบ REST ที่ port 3978
  3. สีม่วง – เป็นการสร้าง bot object และทำการรับฟัง Request ที่จะเข้ามาด้วย path /api/messages เช่น ถ้ามี client เรียก http://localhost:3978/api/messages ตัว bot object จะได้รับ message นี้
  4. สีส้ม – เป็นการจัดการ Dialog (บทสนทนา) ซึ่งจากตัวอย่างจะเป็นการส่งข้อความ “Hello World” กลับไปให้ Client

จากนั้นไปโหลด Bot Framework Emulator มาจาก ทีนี่ ซึ่งตัว Emulator ก็คือตัวที่เอาไว้ใช้ทดสอบ Bot service ของเรานั่นเอง หน้าตาจะเป็นแบบนี้

bot_emu

จากนั้นลองรัน app.js ดูครับ ด้วย command

node app.js

ถ้า Bot เรารันได้แบบไม่มีปัญหาก็จะขึ้น Console แบบนี้ครับ

server_run

กลับมาที่ Emulator ลองพิมพ์อะไรไปแล้ว Enter ดูครับ

bot_send.pngหลังจากพิมพ์ Hi ไป จริงๆแล้วก็คือการส่ง HTTP request ไปที่ http://localhost:3978/api/messages พร้อมกับ JSON payload ที่มี Property “text” นั่นเอง

ส่วนฝั่ง Bot นั้นก็ตอบรับกลับมาเป็น JSON response

bot_recreive.png

ซึ่ง “text” : “Hello World” ก็คือ string ที่ทำการ assign ตอนที่เราเขียน  Code ในไฟล์ app.js

bot.dialog('/', function (session) {
    session.send("Hello World");
});

งั้นเราลองมาแก้เป็น .send() อย่างอื่นแทนเพื่อทดสอบ ก็ได้อย่างที่เห็นครับ

bot_last.png

มาถึงตรงนี้จาก Bot Framework เบื้องต้นตอนนี้อาจจะยังทำให้ไม่ค่อยเห็นว่าจะเอาไปใช้ต่อยังไงได้บ้าง แต่ลองนึกดูว่าถ้าเราสามารถสร้างระบบถาม-ตอบได้อย่างฉลาด เช่นมีการดึง data จากที่ต่างๆ รวมถึงทำ Machine Learning ก็อาจจะทำให้ Bot นั้นมีประโยชน์มากขึ้น ยังไงก็ขอเวลาผมไปลองศึกษาเพิ่มเติมก่อนละกันครับ 🙂

 

Advertisements

Hero Driven Development

วันนี้ผมจะเล่านิทานให้ฟัง….

กาลครั้งหนึ่งนานมาแล้ว ณ หมู่บ้านที่สงบสุขท่ามกลางชีวิตที่เรียบง่ายของชาวบ้านที่ใช้ชีวิตอย่างมีความสุข

Screen Shot 2559-06-26 at 6.33.21 PM.png

สิ่งที่ไม่คาดคิดก็เกิดขึ้น ได้มีมังกรวายร้ายปรากฏตัวขึ้นมาเพื่อทำลายหมู่บ้าน

Screen Shot 2559-06-26 at 6.33.52 PM

ชาวบ้านได้ตื่นตระหนกและทำการสวดอ้อนวอน

Screen Shot 2559-06-26 at 6.35.36 PM.png

ทันใดนั้นเองก็ได้มี คนๆนึงที่ใครๆก็เรียกเค้าว่า ฮีโร่ ปรากฏกายขึ้นมา พร้อมประกายแห่งความหวัง

Screen Shot 2559-06-26 at 6.37.02 PM.png

แน่นอนว่าด้วยความเก๋าของฮีโร่ + กำลังใจอย่างเต็มเปี่ยมของชาวบ้าน
เค้าก็จัดการมังกรร้ายได้อย่างง่ายดาย…

Screen Shot 2559-06-26 at 6.37.34 PM.png

ในที่สุดชาวบ้านก็กลับมาใช้ชีวิตอย่างมีความสุขเช่นเดิม

Screen Shot 2559-06-26 at 6.33.21 PM.png

HAPPY ENDING

(?)

นิทานที่ผมเล่าไปนั้นสามารถตีความให้เกี่ยวกับการพัฒนา Software แบบ Hero Driven Development ได้

ซึ่งนั่นก็คือ..ในทุกครั้งที่มีแหตุการณ์ไม่ปกติ เช่น ปัญหาร้ายแรง/critical bugs/server ล่ม  ทีมงานทุกคนในทีมก็จะเฝ้ารอให้มีคนใดคนนึงที่พวกเค้าเชื่อว่าเก่งที่สุดดังเช่นฮีโร่ จะออกมาแก้ปัญหานี้ให้พวกเค้า และพวกเค้าจะทำหน้าที่นั่งเชียร์ คอยหาขนม และให้กำลังใจอยู่ห่างๆ อย่างห่วงๆ(?)
และเมื่อปัญหานี้ได้ถูกแก้ไป ทีมงานก็กลับไปทำงานตามปกติจนกระทั่งจะเกิดเหตุการณ์นี้ขึ้นอีกในอนาคต….

ปัญหาจริงๆก็คือทีมงานไม่เกิดการเรียนรู้และการแก้ปัญหาด้วยตัวของพวกเค้าเอง ซึ่งถ้าเกิดปัญหาอีกเค้าก็จะเฝ้ารอคนมาแก้ไขให้

ปัญหาเหล่านี้ไม่ใช่ปัญหาของฮีโร่แต่เป็นปัญหาของทีม!

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

และสุดท้ายหวังว่า เราจะสร้างหมู่บ้าน Super HERO ไปได้ด้วยกัน

เรียบเรียงจาก
http://carlokruger.com/?p=35
http://highlevelbits.com/2014/08/hero-driven-development.html

Continuous Deployment ของ Netflix

หลังจากที่ได้พูดถึงการทำ Continuous Deployment (CD) ของ Instragram ไปใน บทความที่ผ่านมา (link)

มาคราวนี้ทาง Netflix ซึ่งเป็น บริษัทที่ให้บริการด้านดูหนังและซีรีย์ออนไลน์ที่มีสมาชิกกว่า 75 ล้านคน

ทาง Engineer ของ Netflix ก็ได้มาแชร์ข้อมูลเกี่ยวกับการ Build http://techblog.netflix.com/2016/03/how-we-build-code-at-netflix.html

เราลองมาดูกันครับ

Netflix นั้นมีหรือ Workflow ตามรูปนี้

pasted image 0.png

ซึ่งกล่องสีขาวคือ Process ของการทำงานจากซ้ายมือไปขวามือ ส่วนสีฟ้าคือ Tools ที่ใช้

ก่อนที่จะลงรายละเอียดแต่ละขั้นตอนทาง Netflix ได้เน้นย้ำไว้ว่าสิ่งที่สำคัญที่ทำให้ Solution นี้เกิดขึ้นมาได้นั้นมาจาก

  1. วัฒนธรรมของบริษัท : ซึ่งก็คือ ความอิสระและความรับผิดชอบ เพื่อที่จะเน้นย้ำให้ทุกคนนั้นได้คิดถึง Solution หรือ Tool ที่ดีที่สุดในการแก้ปัญหาต่างๆได้อย่างเหมาะสม ซึ่ง Tool ที่ดีนั้นควรจะต้อง Add Value และช่วยลดขั้นตอนการทำงานด้วย ซึ่งทาง Engineers นั้นสามารถคิดหา Solution ได้เสมอและต้องคำนึงถึงการดูแลระบบด้วย
  2. Cloud : ทาง Netflix นั้นได้ทำการย้ายระบบจาก Data Center based ไปใช้ Amazon Webservice แทน
  3. Microservices : Netflix ได้เปลี่ยน architecture จากการทำงานด้วยระบบขนาดใหญ่ (monolithic) ไปเป็น Microservices แทน ซึ่ง Microservices นั้นคือการออกแบบให้ Services หรือ API นั้น เล็ก ไม่ซับซ้อน และเป็นอิสระต่อกัน เพื่อที่จะได้แก้ไขแต่ละ Service ได้ง่ายขึ้น

เริ่มจาก

  • Code ทำการ build และ test บนเครื่องของ Developer โดยใช้ Nebula (Tools ของ Netflix เอง)
  • Code Check-in : การ Commit Code เข้า Master branch โดยใช้ Git
  • Continuous Integration : ใช้ Jenkins ในการสั่งให้ Nebular ทำงาน ซึ่งสิ่งที่เกิดขึ้นในขั้นตอนนี้จะประกอบด้วย การ build, test, และการทำ package ที่ไว้ใช้สำหรับการ deploy
  • Bake : ในการ deploy ของทาง Netflix นั้นจะเริ่มจากการ สร้าง Image ของเครื่องใหม่บน Amazon  โดย Image นั้นได้มีการติดตั้งระบบพื้นฐานไว้แล้วเช่น Linux, มี Tools หรือ services ต่างๆพร้อมที่จะใช้สำหรับการติดตั้ง package ใหม่
  • Deployment (Deploy จนถึง Live) : ทาง Netflix ใช้ Spinnaker ช่วยในการทำ pipeline ในการ deploy ต่างๆเช่น เครื่อง Test การจัดการเกี่ยวกับการ deploy หลายๆทวีปพร้อมกัน การทำ canary release เพื่อให้ users ทดลองใช้

สุดท้ายนี้ Netflix ยังได้พูดถึงความท้าทายที่ทางทีมกำลังแก้ไขด้วย เช่น

  1. ปัญหาด้าน dependnecies ของ Java ซึ่งทางทีมก็ได้ปรับปรุงให้ดีขั้นแล้ว
  2. ขั้นตอนของ Bake ให้เวลาเยอะไป ซึ่งปัจจุบันขั้นตอนหลังจาก Code Check-in จน Deploy เสร็จนั้นใช้เวลา 16 นาที แต่เวลา 7 นาทีนั้นใช้ในขั้นตอน Bake ซึ่งเป็น 44% ของเวลาทั้งหมด

ทักษะประจำกาย Developer #3 – Root Cause กับ Workaround?

คำ 2 คำที่คุ้นเคยมากสำหรับเราชาว developer

Root Cause ก็คือ ต้นตอของสาเหตุ
Workaround คือ การแก้ปัญหาอ้อมๆ เพื่อบรรเทาทุกข์

บ่อยครั้งที่ชีวิตในการทำงานของ Developer เราอาจจะหา Root Cause ไม่ได้ในเวลาที่จำกัดแต่เรารู้ว่าปัญหาคืออะไร เช่น

1. เรารู้ว่าการเขียน code แบบนี้มันแก้ปัญหาได้(มั้ง)แต่ไม่รู้ว่าเพราะอะไร นี่เป็นตัวอย่างนึงของ Workaround
2. ระบบของเราทำงานไป 2 วันแล้วทำงานช้าลง เราก็จัดการ restart เครื่องใหม่มันก็หายละ (แล้วอีก 2 วันมันก็ช้าอีก)  นี่เป็นตัวอย่างนึงของ Workaround โดนที่เราไม่ได้มองเลยว่าทำไมระบบทำไมถึงช้าลงได้

หรือยกตัวอย่างง่ายๆ เวลา TV ที่บ้านสมัยก่อนไม่ชัด เราทำไงกันครับ…ตบ TV ไป 2 ที ชัดเลย นี่แหละ Workaround!

การใช้ Workaround บ่อยๆ จะทำให้ทุกอย่างทับถมกันไปหมด จนสุดท้ายระบบก็เละและยากต่อการดูแล

การเป็น Developer ที่ดีเราควรจะหลีกเลี่ยง Workaround และเข้าใจกับ Code ทุกบรรทัดที่เขียนลงไป รวมทั้งการมองปัญหาที่ Root Cause เพื่อที่จะแก้ปัญหาได้อย่างถูกจุดและยั่งยืน ถึงแม้ว่าจะต้องใช้เวลาและความมุ่งมั่นมากกว่าก็ตาม…

ทักษะประจำกาย Developer #2 – คิดเยอะขึ้นอีกนิด

เนื่องด้วยลักษณะงานของ Developer(Dev) คือการพัฒนาระบบใหม่ๆและแก้ปัญหาของผู้ใช้ (users) การพัฒณาความสามารถของเรานั้นจะต้องใช้ความคิดในการแก้ปัญหาและการต่อยอดจากสิ่งที่มีอยู่แล้ว รวมทั้งการสร้างสรรค์สิ่งใหม่ๆให้กับคนบนโลกนี้

เราต้องเพิ่มมุมมองในการมองสิ่งต่างๆ ซึ่งปกติส่วนตัวผมจะฝึกมองและคิดสิ่งต่างๆที่เจอในชีวิตประจำวันเพิ่ม 2 มุม

  1. คิดว่ามันทำได้ยังไง
  2. คิดว่าทำยังไงให้มันดีขึ้น
ยกตัวอย่าง App – LINE ยอดฮิต เชื่อว่าคนไทยเกือบทุกคนที่มี smartphone ใช้ app นี้ โดยปกติเราอาจจะโหลดมาใช้งานทั่วไป ซึ่งก็เป็นปกติอยู่แล้ว
แต่ในมุมมองของ Dev เราคิดต่อไปเลยครับ
“มันทำได้ยังไง” – ลองคิดเลยว่าระบบของ app นี้จะเป็นยังไง ประกอบด้วยอะไรบ้าง มี database หรือว่า infrastructure อะไรบ้าง การทำ User Interface(UI) ประมาณนี้ต้องเขียน Code ยังไง คิดว่าถ้าเราต้องสร้างระบบประมาณนี้จะต้องออกแบบลักษณะไหน ซึ่งการทำแบบนี้บ่อยๆจะทำให้เราได้มี Idea ดีๆเวลาที่เพื่อต้องใช้งานจริงซักวัน
“ทำให้มันดีขึ้นยังไง” – ลองคิดดูว่า app – LINE มันขาดอะไรไป เช่น จะดีกว่านี้มั้ยถ้ามันส่งไฟล์ง่ายๆไม่ได้ หรือจะดีกว่านี้มั้ยถ้ามีระบบตอบรับอัตโนมัติ
การคิดแบบนี้บ่อยๆจนเป็นนิสัย ผมเชื่อว่าจะช่วยให้ตัวเราพัฒนาขึ้น
มาเริ่มเป็นนักคิดกันเถอะ….

ทักษะประจำกาย Developer #1 – การเรียนรู้

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

มันโคตรจะเร็วเลยครับ เอาง่ายๆแค่ลองมองย้อนกลับไป 10 ปีที่แล้วเราเห็นอะไรบ้าง

จาก Desktop Application => Web => Web 2.0 และมาที่ Apps

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

การที่ Developer นั้นยึดติดกับเครื่องมือหรือภาษาที่ใช้ในการพัฒนา software นั้น เป็นเหมือนกำแพงที่จะปิดกั้นการพัฒนาศักยภาพของตัวเอง

การเรียนรู้ด้วยตัวเองในสมัยนี้ก็ง่ายจริงๆ มีทั้ง internet, e-book, youtube และะพวก online course ต่างๆ
เราอาจจะตั้งเป้าหมายว่าทุกๆเดือนเราจะเรียนรู้เรื่องต่างๆเพิ่มขึ้นก็ได้ เช่น เดือนนี้จะรู้เรื่องการเขียน app บน android, เดือนหน้าจะลองเขียนเวปด้วย nodejs, เดือนต่อไปอีกจะลองเล่น Linux ซักครั้ง

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

เนื่องด้วยลักษณะของสายงานของ Developer เป็นแบบนี้แล้ว ทำให้คนในแวดวงนี้อาจจะได้เปรียบคนในสายงานอื่น(มั้ง)ก็คือ เราจะตื่นตัวกับการเปลี่ยนแปลงอยู่เสมอและพร้อมที่จะเรียนรู้ตลอดเวลา ….

ว่าด้วยเรื่องการเพิ่ม Productivity ของ Developers

หลายๆคนอาจจะเคยได้ยินคำว่า Productivity ถ้าแปลตรงตัวเป็นภาษาไทยก็แปลว่า “ความสามารถในการผลิต”
แล้วการเพิ่ม Productivity คืออะไรในแง่ของการพัฒนา software

ผมคิดว่าหน้าที่ของ Software Engineer, Software Developer, Programmer(เรียกรวมๆว่า Developer ละกัน) ก็คือการทำให้ software ที่เป็นไอเดีย สามารถออกมาเป็น Program หรือ App ที่มันทำงานได้จริงอย่างมีประสิทธิภาพ

การที่เหล่า Developer นั้นต้องมานั่งหน้าคอมแล้วทำงานที่ไม่เกี่ยวกับการพัฒนา software สิ่งเหล่านั้นเราควรจะคิดว่ามันเป็นสิ่ง developer ไม่ควรจะเสียเวลาด้วยหรือควรจะเสียเวลาให้น้อยที่สุด ยกตัวอย่างเช่น การประชุมโดยที่ developer ไม่มีส่วนร่วม, การทำงานเดิมๆซ้ำๆ หรือแม้กระทั่งการ copy files ทุกวัน วันละ 2-3 รอบแล้วต้องนั่งรอ

ยกตัวอย่างเช่นถ้างานทุกวันของ Developer คือการ compile source code ที่ให้เวลา 10 นาทีต่อการ compile 1 ครั้ง
วันนึง Developer ต้อง compile ประมาณ 10 รอบ หมายความว่าในแต่ละวัน Developer จะเสียเวลา compile ไป 100 นาที = 1.5 ชม กว่าๆ

ถ้า Developer มีเงินเดือน 30,000 บาท หรือประมาณ 1,500 บาทต่อวัน ( นับ 20 วันทำงาน ) หมายความว่าเราอาจจะเสียเวลาของ Developer ใช้ในการ compile code ประมาณ 300 บาทต่อวัน หรือ 6,000 บาทต่อเดือน

ถ้าเราเอาเงินจำนวนนี้มาอัพเกรดเครื่อง Computer ให้ Developer เพื่อที่จะลดเวลาจาก 10 นาทีเป็น 5 นาที หมายความว่าเราจะมีเวลาให้ developer ใช้ในการทำงาน(เขียนโปรแกรม หรือ ออกแบบระบบให้ดีขึ้น) ซึ่งจะมีประโยชน์มากกว่าการรอ compile….