เรื่องของตัว S (Single Responsibility) ในหลักการ SOLID

Screen Shot 2560-08-23 at 12.04.58 AM.png

หลังจากที่ผมได้เกริ่นเกี่ยวกับหลักการ SOLID ไปแล้วนั้น วันนี้เราจะมาลองดูกันกับตัวแรกของเรา ซึ่งก็คือตัว S ซึ่งย่อมากจาก Single Responsibility หรือแปลว่า หลักการทำหน้าที่เดียวพอ ซึ่งผมจะขอใช้ตัวอย่างด้วย TypeScript ครับ

Single Responsibility Principle (SRP) นั้นกล่าวถึงการออกแบบ Class ในภาษา Object Oriented เพื่อที่จะทำให้ Class นั้นดูแลและจัดการได้สะดวกมากขึ้น

เริ่มต้น ผมมี Class ตัวอย่างที่ชื่อว่า SmartPhone

class SmartPhone {
   // properties
   private apps : Array<string>;
   private contacts : Array<string>;
   private phoneNumber : string;
   private phoneModel : string;
   private screenWidth : number;
   private screenHeigth : number;

   // methods
   public call( telNum : number){
   }
   public ring(){
   }
   public installApp(appName : string){
      this.apps.push(appName);
   }
   public launchApp(appName : string){
      let app = this.apps.filter(element => element === appName);
   }
   public addContact(contact : string){
      this.contacts.push(contact);
   }
   public getScreenPixel() : number {
      return this.screenWidth * this.screenHeigth;
   }
   public getModel() : string {
      return this.phoneModel;
   }
}

ซึ่งจาก Code ตัวอย่างนี้จะเห็นได้ว่า Class SmartPhone นี้ก็ออกแบบมาตามหลัก OO ระดับหนึ่ง ซึ่งถ้าเรามาดูรายละเอียดดีๆนั้นจะเห็นว่ามันมี 3 ส่วนด้วยกัน

  1. การจัดการ Apps
  2. การจัดการ Contact
  3. ข้อมูลของตัว SmartPhone เอง

แต่จะเห็นว่า Code นี้ยังไม่ได้ใช้หลักการของ SRP เลย ดังนั้นสิ่งที่เราต้องทำคือ เราจะมาลองเปลี่ยน Code ให้สอดคล้องกับหลักการนี้ ขั้นตอนนี้เราเรียกว่า การ Refactor 

สิ่งที่ต้องทำก็คือจะใช้เทคนิคการ  Refactor ที่ชื่อว่า Extract Class ก็คือเป็นการแยก Code ในส่วนของ Properties และ Methods ที่น่าจะรวมกันเป็น Class ใหม่ได้ออกมา

ดังนั้นเราเราจะได้ Class ใหม่มาเพิ่มอีก 3 Class คือ Apps และ Contacts

  1. Class Apps จะเอาการเก็บข้อมูล Array และ Methods การ install กับ launch มาไว้ใน Class นี้
class Apps {
   private apps : Array<string>;
   public install(appName : string){
      this.apps.push(appName);
   }
   public launch(appName : string){
      let app = this.apps.filter(element => element === appName);
   }
}

2. Class Contacts จะเอาไว้จัดการเกี่ยวกับ Contact List

class Contacts {
   private contacts : Array<string>;
   public add(contact : string){
      this.contacts.push(contact);
   }
}

3. Class PhoneInfo เราจะเอามาเก็บข้อมูลทั่วไปเช่น เบอร์โทร ชื่อรุ่น ขนาดหน้าจอ

class PhoneInfo {
   private phoneNumber : string;
   private phoneModel : string;
   private screenWidth : number;
   private screenHeigth : number;
   constructor(model : string){
      this.phoneModel = model;
      this.screenWidth =5;
      this.screenHeigth =10;
   }

   public getModel() : string {
      return this.phoneModel;
   }

   public getScreenPixel() : number {
      return this.screenWidth *this.screenHeigth;
   }
}

ซึ่งเมื่อมาถึงตรงนี้แล้วเราก็ต้องทำการแก้ Class หลักของเราก็คือ Class SmartPhone ให้มาเรียกใช้งานทั้ง 3 Classes นี้

// Smart Phone V2
class SmartPhone {
   private apps : Apps; // เรียกใช้ Class Apps
   private info : PhoneInfo; // เรียกใช้ Class PhoneInfo
   private contacts : Contacts; // เรียกใช้ Class Contacts

   constructor(){
      this.apps =new Apps();
      this.info =new PhoneInfo('S10');
      this.contacts =new Contacts();
   }

   public call( telNum : number){
   }

   public ring(){
   }

   public installApp(appName : string){
       this.apps.install(appName); // เรียกใช้ Method ของ Class Apps
   }

   public launchApp(appName : string){
      this.apps.launch(appName);// เรียกใช้ Method ของ Class Apps
   }

   public addContact(contact : string){
      this.contacts.add(contact);// เรียกใช้ Method ของ Class Contacts
   }

   public getScreenPixel() : number {
      return this.info.getScreenPixel();// เรียกใช้ Method ของ Class PhoneInfo
   }

   public getModel() : string {
       return this.info.getModel();// เรียกใช้ Method ของ Class PhoneInfo
   }
}

หลังจากทำการ Refactor เสร็จก็จะเห็นได้ว่า Class SmartPhone Verion 2 นั้นจะเป็นระเบียบมากขึ้น ไม่ต้องมาเก็บตัวแปรที่เป็น String หรือ Array ที่ไม่เกี่ยวข้องอะไรกับตัว Class นี้เองเลย แต่จะย้ายไปเก็บใน Class ย่อยๆแทนเพื่อที่จะให้ Code นั้นเหมาะสมกับ Class แต่ละ Class จริงๆ

เท่านี้เพื่อนๆก็จบหลักสูตร Single Responsibility Principle กันแล้วครับ หวังว่าจะเป็นประโยชน์กับทุกคน แล้วเจอกันตอนหน้าด้วยหลักการตัว O 🙂

หลักการ SOLID สำหรับคนที่เขียน OOP

SOLID เป็นหลักการ 5 ข้อที่จะช่วยให้ Developer ที่เขียนภาษา Object Oriented เช่นพวก C#, Java, C++) นั้นสามารถเขียน Code ได้ดูเป็นระบบระเบียบมากขึ้น รวมถึงสามารถที่จะดูแลและแก้ไขได้ง่ายและสุดท้ายทำให้พวกเราดูเป็น Profressional กันด้วย 🙂

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

เอาล่ะเรามาดูกันว่าหลักการ 5 ข้อนั้นย่ามาจากอะไรบ้าง

S – Single Responsibility Principle

กล่าวถึง Class หนึ่งๆนั้นควรจะมีแค่หน้าที่ ความรับผิดชอบเดียวเท่านั้น

O – Open Closed Principle

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

L – Liskov substitution Principle

กล่าวถึง Object ของ Class ที่ระบบได้เรียกใช้นั้นควรจะสามารถเรียกใช้ Class ลูกๆได้โดยที่ไม่ต้องแก้ไขระบบเลย (ข้อนี้อาจจะเข้าใจยากนิดนึงนะครับ อาจจะต้องลองดูตัวอย่าง)

I – Interface segregation Principle

กล่าวถึงการแบ่งย่อย Interface ให้เป็นสัดสวนตามหน้าที่ของมัน ดีกว่ามี Interface เดียวที่มีหลายๆ Methods

D – Dependency Inversion Principle

กล่างถึงการที่ Class ต่างๆติดต่อกับอีก Class อื่นๆนั้น ควรจะติดต่อกันผ่าน Interface มากกว่า Object ของ Class นั้นๆตรงๆ

 

 

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

ref : https://en.wikipedia.org/wiki/SOLID_(object-oriented_design)

npm แล้วช้ามาลองใช้ yarn จาก facebook กัน

yarn-kitten-full

ทุกๆท่านที่เขียน Node.js ก็ต้องคุ้นเคยกับ npm กันอยู่แล้วนะครับ ซึ่งบางทีเรามักจะเจอว่า มัน install นาน รวมถึงเวลาเน็ตมีปัญหาแล้วมัน install ไม่ได้ มาวันนี้ Facebook ได้ประกาศ Open Source ตัว package manager ตัวใหม่ที่ทำงานบนพื้นฐานของ npm ซึ่งชื่อของมันก็คือ Yarn

ทาง Facebook ได้พูดถึงจุดเด่นหลักๆได้ประมาณนี้ครับ

  1. เร็ว – เพราะมีระบบการ Cache ถ้า pkg ไหนโหลดมาแล้วก็ไม่ต้องโหลด
  2. เชื่อถือได้ – ใช้ในการติดตั้ง package ได้เหมือนเจ้าอื่น
  3. ปลอดภัย – ทำการ check sum ซึ่งเป็นการตรวจเช็คว่าการ install นั้นถูกต้อง

ความสามารถหลักๆของมันคือเช่น

  • Offline Mode ถ้าเคย insatll package มาแล้วครั้งนึง ก็ไม่ต้องใช้ internet ในการ install แล้ว
  • ใช้ประโยชน์จาก Network อย่างเต็มที่ทำให้การ install นั้นเร็วขึ้น
  • ใช้ได้ทั้งกับ npm และ Bower
  • ทำการ retry ถ้าหากว่ามีปัญหาตอน install

อ่านรายละเอียดได้ที่ https://github.com/yarnpkg/yarn และ https://code.facebook.com/posts/1840075619545360 สำหรับ Architure และที่มาที่ไปของ Project นี้ครับ

เกริ่นมาพอแล้ว เรามาลองเล่นกันดีกว่าครับ

ก่อนอื่นก็

npm install -g yarnpkg

แล้วก็ลองเช็คดูครับว่าลงได้

yarnv.png

ที่นี้เดี๋ยวผมลอง install module เล่นๆ เอาเป็น socket.io ละกันครับ ดังนั้นผมสร้าง package.json ง่ายๆมาก่อน

{
“dependencies”: {
“socket.io”: “^1.5.0”
}
}

package.json

ที่นี้ลองรัน “yarn” ซึ่งเทียบเท่ากับ “npm install”

จะเห็นว่าเราจะได้ node_modules มารวมถึงเวลาที่ใช้ไป 3.61s

yarn_install.png

ทีนี้ผมลองลบ folder ‘node_modules’ ทิ้งเพื่อจะดูว่ามัน Offline install ได้จริงเปล่าแล้วก็ทำการ yarn อีกที ผลที่ได้คือ !!! 0.77s

yarn_reinstall

จะเห็นได้ว่า yarn นั้นทำการ cached ตัว package ที่เคยโหลดมาแล้วไว้ที่ Local Machine ซึ่งผมลองไปคุ้ยๆ Folder ดูก็เจอว่ามันไปเก็บไว้ที่  %localappdata%/yarn นี่เองสำหรับบน Windows

local_yarn.png

สรุป ผมว่า Tool ตัวนี้น่าสนใจครับ เดี๋ยวว่าจะเอาไปลองใช้ใน Production บ้าง โดยเฉพาะช่วงเน็ตช้าและต้องงานหลายๆ repo ที่อาจจะมีการใช้ npm package ซ้ำๆกันบ่อยๆ…

Fear Driven Development

จะเกิดอะไรขึ้นถ้า Developer ต้องทำงานอยู่ภายใต้สิ่งแวดล้อมที่มีความกลัวครอบงำ…

ทีมที่ทำงานด้วย Fear Driven Development (FDD) นั้นจะทำให้ Developer นั้นรู้สึกว่า

  • กลัวที่จะทำผิด
  • ไม่กล้าแก้ Code
  • ไม่กล้า Refactor
  • ไม่กล้า Commit หรือ Push Code
  • ไม่กล้าเปลี่ยน Design
  • ไม่กล้าท้าทาย UI/UX หรือ Product เพราะกลัวได้งานเพิ่ม
  • ไม่กล้ารับปาก เพราะกลัวทำไม่ได้
  • ไม่กล้าออกความเห็น เพราะกลัวต้องรับผิดชอบกับ Idea ตัวเอง
  • ไม่กล้าเปลี่ยน Tools หรือ Framework
  • กลัวว่า Software นั้นจะมี BUG ซึ่งเห็นเหตุผลให้เกิด Process ต่างๆมากมาย
  • และสุดท้ายทำให้ Developer ใช้เวลาไปกับงาน Admin/Process มากกว่าการเขียน Code….

ความกลัวและไม่กล้าต่างๆเหล่านี้ทำให้ Project ไปได้ช้าลงแน่นอน รวมถึงทำให้เกิด Over-Engineer (การ Design Software เกิด Use case ที่จะเกิดขึ้นจริง) และกลัวการ Estimate ซึ่งเป็นการบอกเวลาว่า Project นี้จะเสร็จตอนไหนกับเหล่าท่านๆผู้บริหารระดับสูงทั้งหลาย จึงทำให้การ Estimate (ประเมิณ) กลายมาเป็นการลงรายละเอียดซึ่งใช้เวลาเยอะมากจนกว่าจะได้ตัวเลขออกมาก

วัฒนธรรมกลัวตกงาน

เป็นลักษณะหนึ่งของ FDD ซึ่งเกิดจากทีมใช้งาน Developer อย่างหนักและมีการกดดันกันว่าถ้ามีปัญหากับโปรเจคอาจจะโดนไล่ออกได้ ซึ่งการทำแบบนี้ไม่อาจจะทำให้ทีมนั้นมี Productivity ที่ดีได้ รวมทั้งยังขาด Innovation ด้วยรวมถึงทำให้เกิดความกดดันต่างๆและทำให้อัตรา Turn-Over สูงขึ้น ซึ่งในทีมที่มีวัฒนธรรมแบบนี้ส่วนใหญ่ก็จะมีการยกย่องคนที่เรียกว่า Hero(Hero Driven Development) ซึ่งเป็นคนที่ทำให้แต่ละ Release นั้นผ่านไปได้จะได้รับการยกย่องและสุดท้ายก็จะกลายเป็นว่าทีมนั้นต้องการ Hero ตลอดเวลานี่แหละคือปัญหา!

รวมถึงวัฒนธรรมการ Blame เช่นเมื่อเวลามีปัญหาเกิดขึ้นก็หาคนทำผิดแทนที่จะช่วยกันแก้ปัญหาให้ User…

วัฒนธรรมกลัวการแก้ Code

อีกสิ่งที่น่ากลัวของการพัฒนา Software ซึ่งก็คือ Developer ไม่กล้าแก้ไข Code ซึ่งอาจจะเป็นเพราะว่า Code นั้นเก่ามากๆซึ่งปกติน่าจะเกิดจากการที่ไม่เข้าใจ Code ชุดนั้นมากกว่า ลักษณะของ Code ประเภทนี้คือมันก็ work ดีเกือบทุก case แต่ถ้าจะต้องแก้ Developer ก็จะกลัวจะเกิดผลที่คาดไม่ถึง รวมทั้งเกิด Bug ต่างๆ และที่เลวร้ายไปกว่านั้นคือไม่กล้าแก้ Code ของตัวเอง!

สุดท้าย

ส่วนตัวผม คิดว่าสิ่งที่อาจจะน่ากลัวกว่าก็คือการกลัวการเปลี่ยนแปลงโดยเฉพาะ Developer เพราะอย่างที่รู้กันอยู่แล้วว่า Software Development นั้นเทคโนโลยีหรือ Tools ต่างๆมาเร็วไปไว ซึ่งการที่เราไม่ยอมรับการเปลี่ยนแปลงตรงนี้ก็จะคงอยู่แต่โลกเดิมๆ โดยไม่ได้มองหาสิ่งที่จะมาเพิ่ม Productivity ความรู้ใหม่ๆ เพื่อช่วยให้เราเก่งขึ้นและทำงานได้ดีขึ้น 🙂

ถ้า Developer ไม่กล้าแก้ Code แล้วใครจะกล้าแก้ล่ะ???

เรียบเรียงจาก:

http://www.hanselman.com/blog/FearDrivenDevelopmentFDD.aspx

 

สร้าง Node.js module แบบ Native ด้วย C++

node_cpp

เป็นที่รู้กันว่าสำหรับทุกคนว่า Node.js นั้น Powerful ก็เพราะว่ามี Modules ให้เราใช้ไปแทบทุกอย่าง รวมถึงหลายๆคนอาจจะเคยเขียน Module ด้วย JavaScript ทั้งใช้เองและให้คนอื่นใช้

แต่วันนี้ผมจะมาแนะนำวิธีการเขียน Node.js module ด้วย C++ กัน

ก่อนอื่นในเมื่อเราเขียน Module ด้วย JavaScript ได้ทำไมต้องใช้ C++ มาดูข้อดีกันก่อนเลย

  1. System Access – ด้วย Native enviroment ทำให้ Module ที่เขียนด้วย C++ สามารถเข้าถึง API ของ System/OS ได้
  2. Performance – JavaScript นั้นทำงานด้วย Single Thread แต่ว่า Native นั้นสามารทำงานแบบ Multi Thread ได้
  3. Compiled Binary – JavaSciprt ถึงแม้จะมี Minify/Uglify แต่ก็พอจะ reverse engineer ได้แต่สำหรับ Native นั้นถึงแม้จะทำได้เหมือนกันแต่ก็ต้องมานั่ง Deassembly

เริ่มกันเลยครับ จริงๆแล้วผมก็ทำตาม https://nodejs.org/api/addons.html  แต่!…ผมทำตามแล้วมันมีขั้นตอนเยอะและต้องใช้ Python ในการ Build อีก ผมเลยขอสรุปเองจากการลองแงะ Python scipt เพื่อลดความงงลง(หรือว่ายากขึ้น?)

  1. สร้าง Project C++ ใหม่จาก Visual Studio 2015
    newproj
  2. เป็น DLL นะ
    dllproj
  3. ไปโหลด Node.js ไฟล์ headers และ node.lib มาครับที่
    https://nodejs.org/download/release เลือกตาม version ของ Node ที่เราจะใช้ได้เลย เช่น v6.3.0
    download
  4. Extract .gz แล้วก้ copy ไฟล์มาที่ Folder C++ Project ของเรา
    ผมตั้งชื่อ folder เป็น
    – include สำหรับ headers ไฟล์ที่เรา Extracted มา
    – lib สำหรับเก็บ node.lib
    copy_dep
  5. ที่นี้ก็ copy Source code นี้ไปที่ .cpp หลักครับ
    // anurocha_node.cpp : Defines the exported functions for the DLL application.
    //
    
    #include "stdafx.h"
    #include "include/node/node.h"
    
    namespace demo {
    
     using v8::FunctionCallbackInfo;
     using v8::Isolate;
     using v8::Local;
     using v8::Object;
     using v8::String;
     using v8::Value;
    
     void SayHi(const FunctionCallbackInfo<Value>& args) {
     Isolate* isolate = args.GetIsolate();
     args.GetReturnValue().Set(String::NewFromUtf8(isolate, "Hi - How are you doing?"));
     }
    
     void init(Local<Object> exports) {
     NODE_SET_METHOD(exports, "hello", SayHi);
     }
    
     NODE_MODULE(addon, init)
    
    } // namespace demo
  6. ลอง Build Project ดูครับ…เจ๊ง!
    link_err
    อ๊ะ!.. เราลืม Link ครับ
  7. ไปเพิ่ม lib/node.lib ใน Linker ซะ
    linker
  8.  Build อีกรอบ….เจ๊งเหมือนเดิม!!@#ไม่ต้องตกใจครับ….เป็นมุข..เรามี Lib ของ node.dll เป็น x64 ตามที่โหลดมา แต่เรากำลัง Compile แบบ x86 อยู่(ซึ่งเป็น Default Configuration ตอนสร้าง Project) ดังนั้นไปแก้ Project – Linker อีกรอบนึงครับ มั่นใจว่าแก้สำหรับ Platform x64 ด้วยนะครับ
    linker64
  9.  Build อีกทีจริงๆ ด้วย Target x64 นะครับbuildx64
  10. ถ้า Build ผ่านจะได้ไฟล์ .dll มาครับ
    out
    ให้เปลี่ยนชื่อเป็น anurocha.node แทน
  11. สร้างไฟล์ app.js ง่ายๆมา มี Code แค่ 2 บรรทัด ที่ Folder เดียวกับ anurocha.node
    const addon = require('./anurocha');
    console.log(addon.hello());
  12. รัน “node app.js” ดูครับ…..แล้วความตื่นเต้นก็เกิดขึ้น!!!
    node_out

สำเร็จแล้วกับ 12 ขั้นตอนที่ยาวนาน !!!!!

ลองมาดูรายละเอียดกันครับเกี่ยวกับขั้นตอนการทำงานของ JavsScript <–> C++
ซึ่งหัวใจสำคัญที่ทำให้ทั้ง 2 ภาษาคุยกันได้คือ V8 ที่เป็น JavaScript Engine เขียนด้วย C++ จาก Google นั่นเอง

  1. เวลาที่ dll ถูกโหลดด้วย JavaScript จาก require(); ตัว dll จะถูกเรียกครั้งแรกเพื่อทำการ Init ค่าต่างๆ
    ในที่นี้เราทำการ export Fuction ที่ชื่อว่า hello ออกไป ซึ่ง function hello นั้นทำการ Map กับ Method ที่ชื่อว่า SayHi

    void init(Local<Object> exports) {
     NODE_SET_METHOD(exports, "hello", SayHi);
     }
    
     NODE_MODULE(addon, init)
  2. เวลาที่ JavaScript เรียก addon.hello();
    Code ฝั่ง C++ จะถูกเรียก Method ที่ชื่อว่า SayHi(); ทำให้มีการ return String object ที่มีค่า “Hi – How are you doing?” ออกมาให้ฝั่ง JavaScript

    void SayHi(const FunctionCallbackInfo<Value>& args) {
     Isolate* isolate = args.GetIsolate();
     args.GetReturnValue().Set(String::NewFromUtf8(isolate, "Hi - How are you doing?"));
     }

จากตัวอย่างนี้จะเห็นได้ว่าการเขียน Node.js Module ด้วย C++ นั้นอาจจะดูยุ่งยากซักนิดนึง แต่มันทำให้เราเขียน Logic ต่างๆด้วย C++ ได้ นั่นหมายความว่าถ้าเรารัน Node บน Windows เราก็สามารถเรียกใช้งาน Win32 API ต่างๆได้เช่น การเรียก Registry Key, ต่อ Socket, อ่านไฟล์บน HDD รวมถึงการทำงานร่วมกับสารพัด Library ของ C++ อย่างที่ทำได้เหมือนการเขียนโปรแกรมบน OS นั้นๆ….

LONG LIVE C++

ปล. Code ทั้ง Solution ดูได้จาก https://github.com/anurocha/node_cpp_addon ครับ

IDE หนึ่งในสิ่งพื้นฐานควรรู้ของ Developer

Developer คนไหนไม่รู้จัก IDE บ้าง? ถ้าคนๆนั้นเป็นคุณก็…..อ่านต่อเถอะครับ 🙂
ส่วนถ้ารู้แล้วก็ลองอ่านเล่นๆดูได้ครับ

IDE ย่อมากจาก Integrated Development Enviroment ซึ่งก็คือเครื่องมือที่ Developer ใช้ในการพัฒนา Software แบบครบวงจร เช่น Visual Studio, XCode, Netbean, Eclips, Xamarin และอื่นๆ

โดยความสามารถหลักๆ ของ IDE ผมขอแบ่งเป็น 4 อย่างใหญ่ๆละกัน

  1. Editor – เอาไว้เขียน Source Code รวมถึงพวก Syntax Hilight, Auto-Complete
  2. Compiler – เอาไว้ Build โปรแกรมจาก Code ไปเป็น Binary
  3. Debugger – เอาไว้ใช้ในการแก้หาวิธีในการแก้ Bug
  4. Tools – เครื่องมือช่วยต่างๆ เช่น Refactoring, จัดหน้าจอหรือ Visual Design, การทำ UML, ดู Database รวมถึงพวกทำ Static Code Analysis และการสร้าง Document จาก Code

มาถึงตรงนี้แล้วมีใครใช้ IDE ครบ 4 อย่างมั้ยครับ….จากประสบการณ์ของผมแล้วน้องๆ Developer  ส่วนใหญ่จะรู้จักมันในฐานะข้อ 1 และ 2 เท่านั้น

ซึ่งผมอยากแนะนำสำหรับคนที่ยังไม่ได้ลองใช้ความสามารถของ IDE ในการเป็น Debugger ควรจะหาเวลาไปเรียนรู้ไว้ครับ เพราะมันจะช่วยทำให้คุณแก้ Bug รวมถึงพัฒนา Feature ที่ซับซ้อนได้เร็วขึ้นจริงๆ

แต่ช้าก่อน…..ถ้าท่านที่สามารถทำงานกับโปรเจคขนาดใหญ่โดยไม่ต้องใช้ Debugger ได้ผมนับถือมากครับ แสดงว่า  Source Code น่าจะมี Unit Test ครบ 100% ซึ่งทำให้เจอBug ได้จาก Unit Test และไม่ต้องพึ่งการ Debug

นี่คือ Utopia of Software – Software ในอุดมคติเลย!

Canary Testing นกขมิ้นน้อยในเหมืองใหญ่

4_1278772155

เหล่าท่านๆ Engineer ทั้ง Developer และ QA อาจจะรู้ว่าการปล่อย Software ขึ้น Production ให้คุณลูกค้านั้นมีความตื่นเต้นเพียงใด ถึงแม้ว่าเราจะมีการหลายๆ Enviroment ในการพัฒนาระบบเช่น Development, Pre-Production, Production เพื่อลดความเสี่ยงลงแล้ว แต่ถึงอย่างนั้นตอนเอาขึ้น Production ก็ยังต้องลุ้นทุกที

เป็นปกติที่ระบบ Production ของ Software จะมีการ Config ที่แตกต่างกันกว่า Development อยู่เสมอ (แล้วทำไมมันไม่เหมือนกันล่ะ??) แต่ถ้าเราต้องอยู่ด้วยสถานะระบบแบบนี้เรายังมีทางออกนะครับ

สิ่งนี้เรียกว่า Canary Testing ซึ่งมาจาก Canary in Coal Mine มาจาก

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

การนำแนวคิดนี้มาใช้กับ Sofware ก็คือ เราจะให้กลุ่ม Users บางกลุ่มนั้นได้ลองใช้ Software Version ใหม่ก่อนคนอื่นๆ เพื่อป้องกันการความเสี่ยงจากการ Release ที่เดียว Impact ทุกคน หรือเรียกว่า BIG BANG Release
จากนั้นก็ค่อยๆรับ Feedback จาก Users กลุ่มๆนี้ ถ้ามี Critical Bug ก็ทำการแก้ไขก่อนที่จะเริ่ม Release ให้กับ Users ในกลุ่มที่ใหญ่ขึ้น และทำแบบนี้ไปเรื่อยๆจน Release ให้กับทุก Users

ถ้าระบบของ Software เราเป็น Web เราอาจจะทำ Canary Tetsing/Release ได้ง่ายขึ้นจากการ

  1. โดยอาจจะเริ่มจาก กลุ่มผู้โชคดี > ประเทศ > ทวีป > ทั้งโลก เป็น 4 ขึ้นตอน
    ซึ่งอาจจะทำได้โดย detect  ว่า Users มาจาก IP ช่วงไหนแล้วก็ Redirect ไปยัง URL ของ Version ใหม่
  2. ถ้ามีระบบ User อาจจะมี Option ว่าเป็น Early Accessได้ แล้วระบบเราเช็ค Flag นี้ในการตัดสินใจ Version
  3. สร้าง URL ใหม่เลยแล้ว Promote ที่ Banner ว่า Try Latest Version!

ซึ่งแน่นอนว่าการที่ระบบจะทำ Canary Testing ได้ก็ต้องลงทุนและต้องมีสถาปัตยกรรมที่รองรับ และยิ่งถ้าระบบใหญ่ๆและการ Release ทีนึงมี Impact กับ Users เยอะๆนี่ ผมว่าคุ้มนะ 🙂

เริ่มต้นกับ 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 นั้นมีประโยชน์มากขึ้น ยังไงก็ขอเวลาผมไปลองศึกษาเพิ่มเติมก่อนละกันครับ 🙂

 

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 ของ Instagram กัน

เมื่อต้นเดือนเมษายน ทาง Engineer ของ Instagram ได้เขียนบนความของการทำ Continuous Deployment ภายในระบบของเค้า http://engineering.instagram.com/posts/1125308487520335/continuous-deployment-at-instagram

เราจะมาดูกันว่ามีอะไรน่าสนใจบ้าง [ผมแปลแบบสรุปไปด้วยนะครับ ดังนั้นอาจจะไม่ใช่การแปลแบบแป๊ะๆ]

ทำไปทำไม?

Continuous Deployment นั้นมีข้อดีมากมายๆนะครับ ใครไม่รู้จักคำนี้และทำงาน Software Development ที่มีระบบขนาดกลาง/ใหญ่ (ที่มี Developers มากกว่า 10 ละกัน) ควรจะลองศึกษาดู

  1. ทำให้ Developers/Engineers ทำงานได้เร็วขึ้น สามารถที่จะแก้ไขอะไรได้รวดเร็วมากขึ้น
  2. ทำให้ช่วยในการหาข้อผิดพลาดที่เกิดจากการแก้ไขตัวระบบได้เร็วขึ้น จากที่จะต้องมาดูสิ่งที่แก้ไขที่มีเยอะแยะ ก็มาดูแค่รายครั้งที่มีการ Deploy ในแค่ละครั้ง
  3. สิ่งที่ Commit แล้วมีปัญหาก็จะเจอได้รวดเร็วและยังแก้ได้เร็วด้วย

การนำไปใช้

ทาง Instagram นั้นใช้วิธี iterative approach ก็คือไม่ใช้ว่าทำระบบที่เดียวเสร็จแล้วใช้งานทันที แต่จะใช้การค่อยๆพัฒนาทีละจุดไปเรื่อยๆจนกระทั่งเสร็จสมบูรณ์

ก่อนหน้านี้เป็นยังไง

ก่อนที่ทาง Instagram จะมี Continuous Deployment นั้น Engineer จะใช้การ Deploy ตามใจและเวลาที่จะมีการแก้ไข รวมถึงต้องรู้การเช็ค Log และเริ่มการ Deploy ที่ละเครื่องเพื่อทำการทดสอบก่อนที่จะ Deploy ไปที่เครื่อง Servers ที่เหลือ

การทดสอบ/เทส

เริ่มจากการเพิ่มการเทสซึ่งเป็น Script ง่ายๆที่ทาง Engineer ต้องทำจากที่ต้องทำบนเครื่องที่ตั้งใจจะลงบน Production ก็เปลี่ยนมาเป็นทำการ Deploy ที่เครื่อง Canary Machine(เครื่องสำหรับให้ users ทดลองใช้)

จากนั้นมีการสร้างเครื่องที่ทำการทดสอบจาก Git – Master โดยใช้ Jenkins เมื่อเทสของ version ไหนผ่านก็จะมีการแนะนำว่าควรใช้ version นั้นแทนที่จะเป็น version ล่าสุด

การทำงานอัตโนมัติ

เนื่องจากระบบข้างบนแล้ว สิ่งที่ยังเหลือว่าจะต้องให้คนตัดสินใจก็คือ

  1. จะเอา version ไหนไปใช้ในการ Deploy – ซึ่งทาง Instagram ก็เลือกใช้ version ที่ผ่านการทดสอบและมีการเปลี่ยนแปลงไม่เกิน 3 commits
  2. การ Deploy สำเร็จหรือไม่ – หลักการก็คือถ้าไม่สามารถ Deploy ไปที่ servers ได้ด้วยอัตรา 1% จะถึงว่าไม่สำเร็จ

ปัญหา

หลังจากที่ทาง Instagram ได้ทำมาก็พบว่ามีปัญหาใหญ่ๆคือ

เทสไม่ผ่าน

หลายๆครั้งที่ทาง Engineer ได้พบว่ามีการแก้ไข software ที่ทำให้การเทสไม่ผ่าน ซึ่งทำให้ไม่สามารถ Deploy ได้ ซึ่งการแก้ไขนั้นต้องทำการ revert แบบ Manual รวมถึงการเทสที่ใช้เวลานานและไม่ค่อยเสถียร ซึ่งทาง Engineer ก็ได้ทำการแก้ไขให้เทสได้เร็วขึ้นเป็น 5 นาทีจาก 15 นาที

สิ่งที่จะ Deploy

ทาง Instagram พบว่าสิ่งที่จะต้อง Deploy มีมากในคิว เนื่องจากว่าระบบ Canary สามารถดักจับปัญหาได้(ทั้งปัญหาจริง และบั๊ก) ซึ่งทำให้การ Deploy หยุด และต้องมีการแก้ไขด้วย Engineer เพื่อให้ระบบ Automation ทำงานต่อได้ ซึ่งทำให้เกิดการล่าช้าของการ Deploy สิ่งใหม่ๆ ซึ่งทาง Engineerได้แก้ไขปัญหานี้ด้วยการปรับปรุงเงื่อนไขในการทำ Automation deploy ให้ทำงานได้ดีมากขึ้น

หลักการที่แนะนำ

ทาง Instagram ยังได้แนะนำว่าถ้าอยากได้ระบบแบบของเค้า ให้ลองตามนี้

  1. การเทส

    ระบบเทสต้องเร็วและครอบคลุม แต่ไม่จำเป็นต้องสมบูรณ์ และต้องถูกใช้งานบ่อยๆ ทั้งตอน Code Review, ก่อนการ Deploy และหลังจาก Deploy

  2. Canary

    ต้องมีการทำ automated canary เพื่อที่จะป้องกันไม่ให้มีการ commit ที่ไม่ดีเข้าไปอยู่ในสิ่งที่จะ Deploy ลงบน Server ทุกเครื่อง

  3. Automated Test สำหรับการทำงานปกติ

    ไม่จำเป็นต้องมี automate ทั้งหมด แต่เฉพาะสิ่งที่สำคัญจริงๆและเป็นสิ่งที่เกิดขึ้นในเหตุการณ์ปกติ

  4. ทำให้คนรู้สึกมั่นใจ

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

  5. คิดไว้เลยว่าต้องเจอการ Deploy ไม่สำเร็จ

    อาจจะมีโอกาสที่จะมี version ที่ไม่ดีหลุดออกไปบน Production ซึ่งเป็นเรื่องที่ยอมรับได้ แต่ระบบจะต้องตรวจเจอได้เร็วและสามารถแก้ไข้แต่เร็วด้วย

ขั้นต่อไป

  1. ทำให้เร็วยิ่งขึ้น
  2. เพิ่ม Canary
  3. เพิ่มข้อมูล
  4. ปรับปรุงการดักจับข้อผิดพลาด