Debug – Debugger สิ่งนี้คืออะไร

จากที่ผมเขียนเกี่ยวกับ IDE (Integrated Development Enviroment) ไปแล้วนั้น ผมได้เน้นว่าอยากให้ศึกษาเรื่อง  Debugger เพิ่มขึ้น มาคราวนี้เลยขอลงรายละเอียดเลยนะครับ

debug.png

เคยมีโค๊ชที่ผมรู้จักท่านนึงกล่าวไว้ว่าการ Debug นั้นคือศาสตร์มืด เพราะมันเป็นการโกงและไม่ทำให้ Code มีการพัฒนาไปในทางที่เหมาะสม เพราะพอโกงชนะก็มักจะขี้เกียจแก้ Code ให้มันเขียน Unit Test ดีๆได้

แต่ผมคิดว่ามันคือเครื่องมือที่ช่วยเรามากกว่าครับ 🙂

การ Debug ก็คือการวิเคราะห์หาข้อผิดพลาดของ Code ของเราที่มันทำงานไม่ถูกต้องอย่างที่เราคิด ยกตัวอย่างเช่น เราคาดหวังว่า Function จะคำนวณผลมาแบบนึง แต่เราได้ค่าที่ไม่ตรง..หรือว่าเรากดปุ่มนึง แต่ข้อมูลดันออกอีกแบบนึง รวมถึงเวลาต้องการทำความเข้าใจ Workflow ของ Code ที่เราไม่คุ้นเคย ซึ่งปัญหาเหล่านี้ถ้ารู้จักวิธีการ Debug ก็จะทำให้ชีวิตเราง่ายขึ้น

แล้ว Debug กันยังไง? วิธีการ Debug นั้นมีหลายวิธีครับ ขอพูดถึงเฉพาะวิธีที่น่าจะใช้กันบ่อยๆกัน

  1. ไล่ Code ดิบๆ – วีธีสุด Classic คือนั่งเปิด Code ดูแล้วก็รีวิวแบบคิดทุกอย่างในหัว ถ้า Code จุดนั้นไม่ซับซ้อนก็ใช้ได้เหมือนกันครับ
  2. Log – อีกหนึ่งวิธีสุด Classic ที่ใช้การเขียนตัวแปรลงไฟล์ หรือ Console ใช้ได้ดีมากครับ โดยเฉพาะถ้าเราต้องทำที่ระบบปิด เช่น เครื่องของ users หรือบน Production
  3. เช็ค Unit Test – วิธีที่ดีที่สุดและท้าทายที่สุด ซึ่งก็คือถ้าเจอ Bug ก็เพิ่ม Test Case ให้สามารถฟ้องว่าเจอ Bug ได้แล้วก็ทำการแก้ Code ให้ Test ผ่าน จากนั้นเราก็จะได้ Test ที่มันครอบคลุมมากขึ้น
  4. ใช้ Debugger – ซึ่งเป็นสิ่งที่จะพูดถึงต่อไปครับ

Debugger คืออะไร? มันก็คือเครื่องมือช่วยเหลือในการแก้ Bug หรือไล่ Workflow ต่างๆ ซึ่งโดยปกติแล้ว IDE นั้นจะมี Debugger ติดมาให้ด้วยอยู่แล้วสังเกตดูจากเมนูของ IDE ต่างๆครับ จะมีเมนูชื่อ Debug อยู่

เช่น…

Screen Shot 2559-07-19 at 11.58.29 AM.png
Debug ใน XCode
vsdebug
Debug ใน Visual Studio
chromedebug.png
Debug ใน Google Chrome (Developer Tools)

แต่สำหรับ Windows ถ้าไม่อยากลงโปรแกรมแบบหนักๆแบบ Visual Studio เช่นต้องไป Debug  ที่เครื่องของ User ก็มี WinDbg ที่เป็น Debugger แบบ Stand Alone แต่มันค่อนข้าง Advanced มากและเป็น Command Line ผมขอยังไม่พูดถึงนะครับ

ขอทิ้งท้ายไว้กับสิ่งที่ต้องรู้สำหรับการเป็นนัก Debug ละกัน ใครยังไม่รู้จักตัวไหนเจอกันครั้งหน้าครับ

  1. Debug กับ Run
  2. Break Point สกัดจุดหยุดทุกสิ่ง
  3. Call Stack
  4. 3 Steps – Step Over, Step Into, Step Out
  5. หน้าต่าง Watch, Autos, Locals

“If debugging is the process of removing bugs, then programming must be the process of putting them in.” – Edsger W. Dijkstra

ถ้าการ Debug เป็นการจัดการ Bug ให้หมดไป ถ้างั้นการเขียนโปรแกรมก็เป็นการเพิ่ม Bug เข้าไป!

สร้าง 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 เยอะๆนี่ ผมว่าคุ้มนะ 🙂

Microsoft CEO – Satya ทำงานยังไง แล้วพวกเราล่ะ?

ทาง Wall Street Journal ได้ทำ clip 2-3 นาที ซึ่งเป็นการสัมภาษณ์คุณ Satya – CEO ของ Microsoft เกี่ยวกับวิธิการทำงานของเค้าเป็นการถามตอบสั้นๆที่ทำให้รู้จักตัวเค้ามากขึ้น

สิ่งที่ผมดูแล้วชอบเป็นพิเศษคือคำถามที่ว่า

How do you run a meeting? (คุณดำเนินการประชุมยังไง) ใน นาที 1.05

คุณ Satya ตอบได้กระชับมากว่า
Listen More,  Talk Less and be decisive when the time comes” – ฟังเยอะ พูดน้อยแเละเด็ดขาดเมื่อถึงเวลา

ผมรู้สึกถึงพลังของผู้นำที่มีพื้นที่ให้พนักงานได้มีโอกาสแสดงความคิดเห็น มากกว่ารอคำสั่งจาก Leader ซึ่งผมว่าดีมาก

อย่างไรก็ตามสำหรับ Engineer อย่างพวกเราผมว่า

Talk Less, Code more, Show working software”  😉

เห็นด้วยมั้ยครับ…

เริ่มต้นกับ 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

Electron เขียน Desktop Apps ด้วย Web เทคโนโลยี HTML/Javascript

ต้องเรียกว่ายุคสมัยนี้ หากใครเป็น Software Developer แล้วเขียนโปรแกรมได้บน Platform เดียวเช่น Windows ก็คงถือว่าเริ่มจะ Outdated แล้ว

ในอดีตกาลนั้น การเขียนโปรแกรม Desktop ซึ่งก็คือเป็นโปรแกรมหรือ App ที่ใช้งานบน PC/Mac ซึ่งโดยส่วนใหญ่แล้วจะใช้ C/C++, VB, .NET, Java หรือ Objective-C/Swift

ซึ่งจากที่กล่าวไว้ข้างบนนั้นส่วนใหญ่เวลาเขียนมาแล้ว จะเจาะจงว่ามันจะทำงานได้บน OS เดียวเท่านั้น จะมีก็แต่

– Java ที่สามารถเขียนครั้งเดียวแล้วนำไปใช้บน OS อื่นๆได้(ผมไม่แน่ใจว่า Java สามารถใช้งานบน OSX ของ Mac ได้มั้ย)
– C/C++ ก็สามารถเขียนแล้วใช้งานบน Windows/Linux ได้แต่อาจจะต้องใช้ framework ต่างๆช่วยเพื่อให้ Code นั้นไม่ยึดติดกับ OS ใดๆ

แต่เนื่องจากว่ายุค Wep app ครองโลกแบบนี้ และด้วยความที่ HTML, CSS, Javascript ซึ่งเป็น Building Blocks ของ Web techs นั้น ง่ายต่อการทำ UI และสามารถทำงานใต้ Web Browser ใดๆก็ตามที่รองรับมาตรฐานของการพัฒนา Web (HTML5/Es6/Es6) ทำให้ตัว Web techs นั้นมีความได้เปรียบเรื่องการพัฒนา App ให้ Cross Platform

ทางโปรเจค Electron นั้นก็ได้ใช้จุดแข็งตรงนี้มาพัฒนาเป็น Framework ที่ทำให้ Developer สามารถพัฒนาโปรแกรมบน Desktop แบบ Cross Platfrom ด้วย HTML,CSS,Javascript แบบเดียวกับที่ใช้ทำ Web app

จริงๆแล้ว Electron นั้นคือการนำ Open Source ที่นิยมมากสำหรับสาย Web นั่นก็คือ Chromium และ Node.Js มาเป็น Framework เดียว ซึ่งทำให้เราใช้มันสำหรับทำได้ทั้ง UI หรือ Non-UI รวมถึง UI Frameworks ต่างๆเช่น Angular/Polymer/React ก็สามารถนำมาใช้ได้หมด รวมทั้ง Node.Js modules ต่างๆ

เราลองมาเริ่มกัน

  1. เริ่มจากเข้าไปเวปหลัก http://electron.atom.io/ ก่อนเลยครับ
  2. จากนั้นลองทำตาม Quick Start

เพื่อทำการติดตั้งโปรเจคตัวอย่าง

# Clone the Quick Start repository
$ git clone https://github.com/electron/electron-quick-start

# Go into the repository
$ cd electron-quick-start

# Install the dependencies and run
$ npm install && npm start

คำสั่งที่ให้ตัว Electron ทำงานคือ “npm start” และผลจาก sample app คือ ….ทาด้าาาาา..

Hellow World พร้อม Debugger..ในรูปแบบ Desktop App

Screen Shot 2559-06-11 at 9.55.57 AM

มาดูอีกทีแล้วทำไมต้องเราใช้ “npm start” ในการสั่งเปิด App ด้วย จริงๆแล้วเราสามารถสั่งจาก Electron ได้เลยประมาณนี้

$ ./node_modules/.bin/electron .

มาดูรายละเอียดของโครงสร้างของ App กัน

Screen Shot 2559-06-11 at 10.50.34 AM

ไฟล์ที่สำคัญคือ

  • index.html แน่นอนครับเป็นหน้า UI หลัก
  • main.js แน่นอนครับเป็น Entry point ของโปรแกรมเรา
  • package.json เป็นไฟล์ Config สำหรับ NodeJs

มาลองดูไฟล์ main.js กันก่อนครับ จะเห็นว่ามีการสร้าง BrowserWindow ขนาด 800×600 แล้วทำการโหลด index.html เป็นหน้าแรก ซึ่ง BrowserWindow คือการเปิด Web Browser Window (ที่ใช้ Chromium ในการ render นั่นเอง)

function createWindow () {
 // Create the browser window.
 mainWindow = new BrowserWindow({width: 800, height: 600})

 // and load the index.html of the app.
 mainWindow.loadURL(`file://${__dirname}/index.html`)

 // Open the DevTools.
mainWindow.webContents.openDevTools()

 // Emitted when the window is closed.
 mainWindow.on('closed', function () {
 // Dereference the window object, usually you would store windows
 // in an array if your app supports multi windows, this is the time
 // when you should delete the corresponding element.
 mainWindow = null
 })
}

และ Code “mainWindow.webContents.openDevTools() น่าจะเป็นการ Debugger Window ที่นี่เราลองลบบรรทัดนี้ดูแล้วรันใหม่ ก็จะเห็นว่า Debugger หายไปแล้ว

Screen Shot 2559-06-11 at 11.01.21 AM.png

ที่นี้มาลองดู index.html กันครับ ดูแล้วก็ไม่มีอะไรมาก

<!DOCTYPE html>
<html>
<head>
<meta charset=”UTF-8″>
<title>Hello World!</title>
</head>
<body>
<h1>Hello World!</h1>
<!– All of the Node.js APIs are available in this renderer process. –>
We are using node document.write(process.versions.node),
Chromium document.write(process.versions.chrome),
and Electron document.write(process.versions.electron).
</body>

// You can also require other files to run in this process
require(‘./renderer.js’)

</html>

เรามาลองแก้ HTML ง่ายๆกันเพื่อทำ Contact card app เอาไว้แนะนำตัว

Screen Shot 2559-10-08 at 9.32.48 AM.png

ผลที่ได้ก็คือ

Screen Shot 2559-06-11 at 11.42.28 AM

เมื่อกดปุ่ม More Info.. จะทำการเปิด MessageBox เพื่อแสดงข้อความ

Screen Shot 2559-06-11 at 11.44.51 AM

สรุปได้ว่าเราสามารถเขียน App ที่มี ประสพการณ์แบบ Desktop ด้วย HTML/Javasctipt ได้ง่ายๆ(?) โดยใช้ Framework Electron ครับ….

13409222

Final Fantasy X/X-2 HD Remaster กับ Windows architecture

พอดีได้ข่าวว่า Final Fantasy X ได้ทำการ Port มาลง PC ก็เลยลองเล่นดูครับ เพราะภาคนี้ผมเล่นตอน PS2 ได้ประมาณ 30-40% แล้วก็ไม่ได้เล่นต่อเนื่องจากติดทำ Project จบสมัยเรียน เลยขายเครื่องทิ้งไปเพราะกลัวเรียนไม่จบ 🙂

แต่ที่เขียนถึงวันนี้คงพูดถึงเรื่อง Windows architecture กันนิดหน่อย

สืบเนื่องมาจากว่า ผมเล่นเกมนี้ไปได้ประมาณไม่นานเช่น 10-20นาที โปรแกรมก็ Crash ซึ่งมาจากขั้นตอนที่ไม่แน่นอน หรือเรียกว่า Random Crash นั่นเอง

ซึ่งการ Crash ของ Application นั้นก็หมายถึงการที่โปรแกรมหยุดทำงานด้วยสาเหตุใดสาเหตุหนึ่งแล้วโปรแกรมก็เด้งออกอัตโนมัติทิ้งให้เราอึ้งไปหลายวิ..

As User

จากการที่เราเป็น End User ของเกมนี้ก็ แน่นอนครับ ติดปัญหาเราก็ต้องลองหาใน Google ดูก็ก่อนเลย ซึ่งก็พบว่ามีหลายๆคนเจอปัญหาเดียวกัน

http://steamcommunity.com/app/359870/discussions/0/364042063114641626/
http://steamcommunity.com/app/359870/discussions/0/364042262885080038/
http://steamcommunity.com/app/359870/discussions/0/364042262879682906/

ซึ่งผมลองทำตาม workaround ต่างๆแต่ก็ยังไม่สำเร็จ เล่นไปสักแป๊บนึงเกมก็เด้งออกมาอีกเช่นเคย

As Developer

แต่ด้วยความที่เราก็ Developer ผมก็ตัดสินใจลอง Investigate ปัญหานี้ดูด้วยตัวเอง

สิ่งแรกที่ผมเห็นคือเวลามัน Crash ตัวไฟล์ CoreDump.dmp จะถูกสร้างขึ้นมา

coredump.png

ลองเปิดด้วย Visual Studio เพื่อทำการ Analyze Dump ไฟล์ได้ข้อมูลน่าสนใจตามนี้

dumpinfo

  1. Process นี้เป็น x86 ก็คือ 32 Bits
  2. Crash ที่เกิดขึ้นมี Exception เกี่ยวกับ Virtual Address หรือ Virtual Memory นั่นเอง

พอรู้แบบนี้ผมก็ลองเปิด Process Explorer ดูเลยครับว่าเวลาเล่นเกมนี้ มันใช้ Memory ขนาดไหน ปรากฎว่า…

ชัดเจนครับแค่เปิดเกมมา Virtual Memory ก็1.9GB แล้ว

screen

memreach

นี่คือสาเหตุของปัญหานี้ครับ..เนื่องจากว่า เกม(Process) นี้ถูก Compile ด้วย 32 Bits ทำให้สามารถใช้งาน Memory Space ได้ 2^32 bytes หรือประมาณคร่าวๆได้ 4GB (4,000,000KB โดยประมาณ)

แต่เนื่องจาก Windows Architect นั้นได้ทำการแบ่ง Memory ไว้เป็น 2 ส่วนคือ Kernel space กับ Application space (User space) อย่างละ 2GB

ซึ่งง่ายๆก็คือ Applicatoin จะใช้ได้ 2GB เท่านั้น ทำให้ถ้าใช้เกินโปรแกรมก็จะ Crash (ถ้าจัดการไม่ดี)

วิธีแก้ปัญหา

Windows นั้นได้มี Feature ที่เรียกว่า Large Address Aware ซึ่งทำให้ Application สามารถใช้งาน Memory ได้มากกว่า 2GB นั่นเอง

Tool ตัวนี้คือ Editbin.exe ซึ่งติดตั้งมากับ Microsoft Visual Studio อยู่แล้วครับ

พิมพ์ไปเลยครับตามนนี้

editbin /largeaddressaware “D:\Games\Final Fantasy X\FFX.exe”

editbin.png

เราก็จะได้ FFX.exe ตัวใหม่ที่ทำการเปิด Feature Large Address Aware แล้ว และเมื่อลองทดสอบดู Process ของเกมนี้ก็สามารถใช้ Memory ได้เกิน 2GB แล้ว

final_mem

และสุดท้ายตั้งแต่ผมแก้มาก็เล่นได้ 4-5 ชั่วโมงได้ไม่เจออาการ Crash/Freeze อีกเลยครับ 🙂

 

English:

For english guys (if any), I found one potential workaround to solve the random crash/freeze issues on FFX HD Remaster on PC. I think the issue is around memory reach limit of 32 Bits process which is 2GB for application space(from totally 4GB  – kernel and app/user space) which FFX has been built as 32 Bits app.

so once you configured the game with high graphic settings. it uses higher memory and might be able to trigger the issue more eaiser.

we can use the tool called “editbin.exe” which is the small utility to allow us to change the flag of the process which is “/largeaddressaware” that can help to incrase the app/user space of memory up to 3/4GB based on OS. but at least it will be higer than 2GB as system default.

you can find “editbin” from Visual Studio.

and after I applied this flag. I can play the game for 4-5 hours for 2 days without any crash. hope this can help for some.

 

HAPPY GAMING…

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% ของเวลาทั้งหมด