Node.js เขียน REST API ด้วย LoopBack

powered-by-LB-med.png

เนื่องจากผมอยากลองเขียน REST ง่ายๆเอาไว้ลองกับงาน Side Project ดูครับ ส่วนตัวแล้วเคยจับ Express มาบ้างแบบน้อยนิด ซึ่งปกติก็ต้องมานั่งเขียน Route กันเองแล้วมาเช็ค Path เลยหา Framework อื่นดู ก็เจอว่ามีทั้ง Sails, Restify และอื่นๆ แต่ลองนึกดูเคยมีคนพูดถึง LoopBack ให้ผมฟัง ผมเลยลองมาใช้ตัวนี้ดีกว่า เพราะเห็นว่า IBM เป็นผู้สนับสนุนรายใหญ่ซึ่งจริงๆแล้วพัฒนาโดย StrongLoop

ก่อนอื่นเข้าไป official site https://loopback.io/ ก่อนเลย ก็เจอว่า Get Started ไม่มี Code ตัวอย่างเลยครับ งั้นมันทำงานยังไงกันนี่ เรามาลองดูกัน

ก่อนอื่นเท่าที่ผมเข้าใจ LoopBack เนี่ยจะใช้แนวคิดเรื่อง Model มากกว่าการ Route ซึ่งหมายความว่าการที่เราจะเพิ่ม API เข้าไป ก็จะเป็นการทำงานเกี่ยวข้องกับ Model (เหมือนกับการเขียน function handler ของ Model) เพราะหน้าที่การ Route นั้น LoopBack จัดการให้เราหมดแล้ว ผ่าน Express นั่นแหละ….

เริ่มแรกเราต้อง Install ตัว LoopBack ก่อนครับ (เป็น commandline interface – CLI)

$ npm install -g strongloop

หลักจากนั้นเราจะต้องทำการสร้าง Project จาก Template ครับด้วย

$ slc loopback

จากนั้นเราจะต้องทำการตั้งชื่อ Project เลือก Directory รวมถึงเลือก LoopBack version

create-proj.png
ผมตั้งชื่อว่า loopback-aro

สิ่งที่ได้คือ Folders และ ไฟล์ต่างๆหน้าตาแบบนี้โดยผมสร้าง Project แบบ api-server ฉะนั้นส่วนที่จะต้องแก้น่าจะทำใน Folder ชื่อ server

folder-struct.png

หลังจากนั้นเราก็ลองทำการสร้าง Model กันครับ เพราะอย่างที่ผมบอกไปข้างต้นว่า loopback นั้นใช้ Model driven ในการพัฒนา REST API

 

$ slc loopback:model

ผมจะสร้าง Model ง่ายๆใช้สำหรับเก็บข้อมูล user ละกันครับ ตัว CLI มันก็จะให้เราตอบไปว่าจะใช้ Feature อะไรของ LoopBack บ้าง เช่น

  • จะใช้ data-source แบบไหน (ค่าปกติคือ memory ซึ่งใช้สำหรับการ Dev เพราะไม่งั้นเราปิด server แล้วค่าจะถูกลบทิ้งครับ เพราะ memory ถูกคืนให้ OS)
  • ใช้ PersistedModel เพื่อทำใช้สามารถเก็บ Model เข้า database ได้ง่าย
  • ทำการเปิด REST API สำหรับ Model ตัวนี้
  • และ อื่นๆ

create-model.png

ที่นี้ผมก็จะสร้าง properties หรือ attibutes ของ user ครับ โดยที่มี

  • name เป็น string
  • score เป็น number

create-prop.png

เมื่อสร้างเสร็จแล้วเราก็จะเห็น Folder ชื่อ common ถูกสร้างขึ้นมารวมทั้งมี Subfolder ชื่อ Model ที่มีไฟล์ user.js/json ซึ่งตรงกับที่เราสร้างข้างต้น

common-folder.png

เราจะเห็นว่า

  • user.js คือ code javascript เปล่าๆ (ที่เอาไว้ให้เราเขียน logic สำหรับ expose REST API เพิ่ม)
  • user.json นั้นจะเป็นการประกาศพวก Properties ต่างๆ (หมายความว่าเราไม่ต้องใช้ CLI ในการสร้าง Model ก็ได้ถ้าเรารู้จักโครงสร้างของ Framework)

model-files.png

ที่นี้เราลองมารันดูครับ

node .

run.png

ลองเข้าผ่าน localhost:3000/explorer ดูก็จะพบว่ามี API Tool (หน้าตาเหมือน Swagger ให้เลยครับ)

explorer

เรามาลอง POST เพื่อสร้าง Model object ดีกว่า

anurocha-80.png

จะเห็นว่าหลังจากกดปุ่ม Try it out! ก็จะทำการยิง http request ไปที่ /api/user และได้รับ message ตอบรับว่า 200 และได้รับ id:1 เป็นค่า key

anurocha-res.png

ดังนั้นถ้าผมลอง GET ด้วย id :1 เราควรจะได้ object นี้กลับมากนะครับ ลองผ่าน Postman (ซึ่งเป็น Tool ที่ใช้ได้การส่ง HTTP request) กันดีกว่า

ได้ response ตามคาด!

get-postman.png

จะเห็นว่าการสร้าง REST API แบบง่ายๆด้วย LoopBack นี่ไม่ต้องเขียน Code เลยซักบรรทัด

แต่ความสามารถของ LoopBack ยังมีอีกเยอะ เช่นการ Extend API ให้ซับซ้อนยิ่งขึ้น การติดต่อกับ Data-source แบบอื่นๆเช่น MySQL หรือ MongoDB เจอกันคราวหน้าครับ 🙂
Notes:

เพิ่ม API อ่านต่อได้เลย

ตัวเลขมหัศจรรย์ Magic Number

สิ่งหนึ่งที่ผมเชื่อว่า Developer ทุกคนเคยทำก็คือการเขียน “ตัวเลขมหัศจรรย์” ลงไปใน Source Code แล้วมันคืออะไรล่ะ

Magic Number ก็คือตัวเลขที่อยู่ใน Code แบบโผล่มาแบบงงๆลอยๆ โดยที่ไม่มีใครรู้ที่มาเลย (นอกจากคนเขียน ซึ่งผ่านไป 3 เดือนก็ลืม 55)

ยกตัวอย่าง Magic Number กันแบบง่ายๆก่อน

            for (int i = 0; > 50; ++i)
            {
                Console.WriteLine("Hello");
            }

ในกรณีนี้ Magic Number คือ “50” เพราะอยู่ดีๆมันก็โผล่มา ถ้าคนมาทีหลังอาจจะงงว่า 50 คือเลขอะไร ตั้งใจเขียนมารึเปล่า

วิธีแก้ปัญหาอย่างง่ายที่สุดคือเราเปลี่ยนมาใช้ตัวแปร const แทนครับ (สำหรับ C++/C#)

            const int LOOPTIME = 50;
            for (int i = 0; i > LOOPTIME; ++i)
            {
                Console.WriteLine("Hello");
            }

ซึ่งจะทำให้ Code เรานั้นรู้ว่าเราต้องการ Loop 50 รอบจริงๆนะ ไม่ใช่พิมพ์ผิดอะไร

ตัวอย่างที่ 2

ผมมี Method/Function นึงทำอะไรบางอย่างแบบนี้

       static public double CalPrice(int price)
        {
            return price + (price * 0.07);
        }

แน่นอนครับ Magic Number ก็คือ 0.07 ที่ Code ผ่านไป 3 เดือน เราก็จะงงว่าทำไมมันต้อง 0.07 ด้วย นี่มัน Method เอาไว้ทำอะไร

เราก็แก้ด้วยวิธีเดิมครับคือการใช้ตัวแปร const มาแทน พร้อมตั้งชื่อให้สื่อความหมาย

        private const double VAT_RATE = 0.07;
        static public double CalPrice(int price)
        {
            return price + (price * VAT_RATE);
        }

โอ้ว นี่คือ การบวก Vat 7% นี่เอง!!!

เอาล่ะที่นี้เรารู้จัก Magic Number กันแล้ว มาลองสรุปกันดีกว่า

ข้อดี :

  • เขียนง่าย
  • เร็ว
  • อ่านแล้วจบ
  • ดูแล้วเหมือนจะสบายตา (ช่วงที่เพิ่งเขียนเสร็จ)

ข้อเสีย :

  • คนอื่นมาอ่าน Code อาจจะงง
  • แถมหนักกว่าอีกเพราะคนเขียนเองก็งงถ้าผ่านไปซักระยะ
  • Code อาจจะ Maintain ยากขึ้นเพราะมี Magic Number ทำให้คนที่ไม่รู้ ก็จะไม่กล้าแตะ และต้องมานั่งไล่ Logic ถ้าต้องการแก้

มาถึงตรงนี้ลองกลับไปดู Code ที่เป็น Production ของเรากันสิว่า คุณเป็นนักมายากล Magic Number กัน(มาก)รึเปล่า

piq_52779_400x400
I love Magic (but sorry not Magic Number!!) 

Note* Picture from Final Fantasy

 

เส้นทางสู่ Developer ระดับโลก (มั้ง)

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

และในฐานะที่เป็น Developer ผมขอกล่าวถึงเฉพาะมุมมองของ Devloper ดังนั้นตัดส่วน Business ทิ้งไปเลย

1. อยู่กับ Techonology ที่ Project ใช้อย่าง Expert

เป็น Developer ที่อาจจะเก่งหรือทำงานได้ในระดับหนึ่งของ Project ที่ตัวเองนั้นทำอยู่ อย่างน้อยควรจะต้องรู้ว่า Technology ที่ตัวเองใช้อยู่มี Best Practices อะไร รวมถึงรู้ว่ามี Trap อะไร อาจจะได้มีโอกาสศึกษาอะไรใหม่ๆบ้างถ้าทาง Project นั้นต้องการใช้

กลุ่มนี้ คุณๆอาจจะใช้ Technology ล่าสุดในวันนี้เพราะทีมหรือ Project ใช้อยู่ แต่จริงๆไม่ควรรอทีมนะ ไม่งั้นผ่านไป 2-3 ปีแล้วยังอยู่แต่กับ Technology นี้ก็จะ Outdate ได้ง่ายๆ

2. ติดตามข่าวสาร IT หรือ Tech อย่างสม่ำเสมอ

เป็น Developer ที่รู้ว่าแต่ละ Products หรือว่า Tools หรือ Frameworks มีอะไรออกใหม่บ้างทำให้มี Idea ในการที่จะพัฒนา Project ที่ตัวเองทำอยู่เพราะได้รับ Input ใหม่ๆ

กลุ่มนี้อาจจะต้องระวังกับดักที่ว่าเราดันสนใจแต่ข่าว Consumer เช่น Apple ออก Product อะไรใหม่, Android ออกรุ่นใหม่ หรือ Program/App นู่นนี่มี Update อะไรบ้างเพราะปัจจุบันนี้ข่าวพวกนี้ใครๆเค้าก็รู้กันแล้วครับ

ผมมองว่าระดับนี้ต้องติดตามข่าวสำหรับ Software Development นะครับ

3. ลองใช้ Tech ต่างๆที่ใหม่ๆที่ตัวเองสนใจ

เป็น Developer ที่นอกจากจะติดตามข่าวสารต่างๆแล้ว ยังใช้เวลาทำการลงมือศึกษาเองด้วย อาจจะเป็นลักษณะเอามาทำ Prototype ของ Project ที่ตัวเองทำอยู่ หรือเป็น Side Project แบบทำเล่นๆ (หรือทำขายจริงจัง) ผมว่าอยากให้ทุกๆคนอย่างน้อยๆมาอยู่จุดๆนี้กันครับ

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

4. Contribute ให้กับ Community ต่างๆ

เป็น Developer ที่สามารถเข้าไปมีบทบาทในชุมชนต่างๆ เช่นงาน Event หรือการมีส่วนร่วมในการพัฒนา Open Source ผมเห็นปัจจุบันมีเยอะมากๆ น่าดีใจจริง คนไทยเทพพพพพ

ผมอยากเห็น Developer ไทยมาถึงจุดๆนี้กันเยอะๆ (รวมถึงตัวผมเองด้วย)

5. สร้าง Community ใหม่ๆเอง!

เป็น Developer ที่เป็นคนคิด Community ต่างๆได้โดยเฉพาะ Framework ที่ให้คนอื่นมาช่วย Contribute และได้รับการยอมรับจาก Community

กลุ่มนี้ผมไม่สามารถ Comment ได้ครับเพราะยังไม่ถึงขั้น (5555) แต่ผมว่านี่แหละ Developer ระดับโลก!!!!!

 

ป.ล. บทความนี้เป็นความเห็นส่วนตัวล้วนๆและเอาไว้เตือนใจตัวเองครับ 🙂

ทักษะประจำกาย Developer #7 – มาพร้อมวิธีแก้ปัญหา

การที่จะเป็น Developer ที่เก่งกว่าคนทั่วไปนั้น เราควรจะต้องมีนิสัยอีกอย่างนึงที่ขาดไม่ได้คือ การชอบแก้ปัญหา

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

Come with Solution, not problem

ขั้นตอนที่ผมใช้บ่อยที่สุดในการไปขอความช่วยเหลือคนอื่นคือ

  1. ศึกษาสิ่งที่เกี่ยวข้องกับปัญหาด้วยตัวเองก่อนให้ได้มากที่สุด
  2. ลองแก้ปัญหาด้วยวิธีต่างๆหลายๆวิธี ถ้ามีคำตอบหลายวิธีทำการวิเคราะห์ข้อดีและข้อเสียของแต่ละวิธี เพราะผมเชื่อว่าปัญหาต่างๆ น่าจะมีวิธีแก้ไขได้มากกว่า 1 วิธี
  3. หาจุดยืนในวิธีที่เราเองคิดว่าดีที่สุด
  4. ลุยยย ไปขอคำปรึกษาผู้รู้กัน

ยกตัวอย่าง(แบบกว้างๆ) เช่น  ผมมีปัญหาว่า Server ที่ผมดูแลทำงานช้าจัง ถ้าผมไปถามคนอื่นทันทีอาจจะไม่ได้คำตอบแน่นอน เราก็ต้องลองมาทำงานการบ้านกันก่อน เช่น

  1. ไปศึกษาว่าระบบช้าเพราะอะไร สมมติว่าเจอว่า CPU ทำงานหนักตลอดเวลา
  2. ลองแก้ปัญหาดูเราอาจจะพบว่ามีทางออก 2 ทาง
    A. อัพเกรด CPU ให้เร็วขึ้น
    ข้อดี – แก้ปัญหาได้ 20%
    ข้อเสีย – ใช้งบ 30,000 บาทต่อ Server และอาจจะมี  Downtime สูง
    B. ปรับปรุง Software ให้ดีขึ้น
    ข้อดี – รีดประสิทธิภาพครื่องปัจจุบันได้ดีขึ้น ดูเป็นวิธีของ Engineer ดีและประหยัดงบ
    ข้อเสีย – อาจจะต้องใช้เวลาในการแก้ไขมากซัก 1 เดือน
  3. ผมชอบ ทางเลือกที่ B นะดูท้าทายดี
  4. จากนั้นก็ลองไปปรึกษาคนอื่นๆในทีมงานว่ามันเป็นไปได้มั้ย

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

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

 

รัน Typescript ผ่าน Node ตรงๆด้วย ts-node

ปกติแล้ว Node.js นั้นจะทำการ execute JavaScript เท่านั้น ซึ่งถ้า Developer นั้นอยากเขียน Project ด้วย TypeScript ก็จะต้องทำการ compile จาก .ts ให้เป็น .js ก่อน

พอดีเห็น GitHub มีโปรเจคหน้าสนใจชื่อว่า ts-node ซึ่งทำให้เราสามารถรัน .ts ไฟล์ได้ตรงๆเลยครับ
Link: https://github.com/TypeStrong/ts-node

การใช้งานก็คือรัน commandline นี้เพื่อทำการรัน Node

ts-node main.ts

มาลุยกันครับ

เริ่มจากเรามี TypeScript file (.ts) ที่สั่งสร้าง http server ชื่อ main.ts

import * as http from "http";

class HttpServer {
private server : http.Server;
public start(){
this.server = http.createServer( (request, response) => {
response.write('Hello...!');
response.end();
});

this.server.listen(8080);
console.log("start server...");
}

public stop(){
this.server.close(()=>{}
);
}
}

let serv = new HttpServer();
serv.start();

ทีนี้เราก็ลอง install ts-node ก่อนครับ

npm install ts-node

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

ts-node main.ts

เวิร์คดี!!

runable.png

ถ้าเรามาลองดู Process Tree เราก็จะพบว่าจริงๆแล้วตัว ts-node นั้นก็ทำการรัน node process และทำการรัน bin.js ซึ่งเป็น code ของ ts-node เพื่อให้มันสามารถรัน main.ts ได้

process_tree.png

สรุปแล้วผมคิดว่าโปรเจคนี้น่าสนใจนะครับ เพราะช่วยลดขั้นตอนการ compile ไป JavaScript ไป 🙂
ทั้งนี้ทั้งนั้นต้องทดสอบว่าถ้าเป็นโปรเจคที่ซับซ้อนจะเป็นยังไงบ้าง…

Node.js – Profiling เพื่อดูว่า Code เรากิน CPU รึเปล่า

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

ซึ่งขั้นตอนที่ขาดไม่ได้สำหรับการวัดประสิทธิภาพของ Code ก็คือ สิ่งที่เรียกว่า Profiling

ซึ่งทาง Node.js Tools for Visual Studio ก็มีเครื่องมือนี้มาให้ด้วย ซึ่งปกติเครื่องมือช่วยการทำ Profiling เราก็เรียกง่ายๆว่า Profiler  (Features อื่นๆ อ่านเพิ่มเติมจาก link นะครับ)

ถ้าผมมี Code ตัวอย่าง JavaScript ประมาณนี้

console.log('Hello world');

for (let i = 0; i < 50; ++i){
    let rand = getRandomNum(10000000);
    print(rand, calSum(rand), findDivideBy5(rand));
}

function getRandomNum(max) {
    return Math.floor((Math.random() * max) + 1);
}

function calSum(num) {
    let sum = 0;
    for (let i = 0; i <= num; ++i) {
        sum += i;
    }
    return sum;
}

function findDivideBy5(num) {
    let n = 0;
    for (let i = 0; i <= num; ++i) {
        if (i % 5 == 0) {
            n++;
        }
    }
    return n;
}

function print(rand, sum, count5) {
    console.log("number : " + rand);
    console.log("Sum of 0 to " + rand + " is " + sum);
    console.log("Can divide by 5 count of 0 to " + rand + " is " + count5);
    console.log("----------------------");
}

 

Code นี้ทำอะไรบ้าง?

เป็นการสุ่มค่ามาค่านึง (N) แล้วก็
1. หาผลรวมของ 0 ถึง N – function calSum()
2. หาจำนวนของตัวเลขระหว่าง 0 ถึง N ที่หารด้วย 5 ลงตัว – function findDivideby5()
3. แสดงผล – function print()

คำถามคือ Code ตรงไหนช้าที่สุด…เรามาดูกัน

เราสามารถเริ่มการทำ Profiling จากเมนูนี้

menu

เมื่อ app ทำงานจบหรือเราหยุดการทำงานก่อน Visual Studio ก็จะทำการสร้าง Report มาให้เราอย่างละเอียด

fullreport

เรามาดู Hi-light ที่สำคัญกันครับ

  1. Code นี้ใช้พลัง CPU ไป ~20% ซึงเครื่องผมมี 4 Cores แล้วว่าทำงานไปเต็มๆ 1 Corecpu_usage
  2. มาดูระดับ Function กันครับ ปรากฎว่า app.calSum เป็นผู้ชนะไป (หมายความว่าแย่สุด เพราะใช้ CPU ไปเยอะที่สุด)function_usage
  3. นอกจากนี้ยังสามารถดู Call Tree เพื่อที่จะได้รู้ว่าแต่ละ Function ถูกเรียกมาได้ยังไง รวมถึงใช้ CPU ไปมากน้อยเท่าไหร่
    เช่น จากตัวอย่าง Top level (หรือ Global) นั้นได้ทำการเรียก function calSum() กับ app.fineDivideby5()call_tress

จากตัวอย่างนี้จะเป็นว่าการทำ Profiling นั้น ช่วยให้เราสามารถวิเคาะห์ปัญหาเกี่ยวกับการใช้งาน CPU ได้สะดวกยิ่งขึ้น แต่ทั้งนี้ทั้งนั้น นอกจากการใช้งาน CPU แล้ว สิ่งที่ควรจะทำการ Profile ก็ควรจะมีทั้ง Memory รวมถึง HTTP Resource หรือ Disk I/O ด้วย (แต่เหมือน Visual Studio ยังไม่ Support สำหรับ Node.js มั้งครับ ผมหาไม่เจอ 55)

Artwork – กิจกรรมยามว่าง

ผมชอบงานออกแบบของ Yoshitaka Amano (ผู้ออกแบบงานศิลป์ของ Final Fantasy) เป็นพิเศษ ทำให้ผมได้รับแรงบันดาลใจในการพยายามเอาลายเส้นมาใช้

Link จาก The Legend of Zelda : Breath of the Wild

Casca จาก Berserk

Griffith – Femto จาก Berserk

Node.js Tools for Visual Studio มีดีอะไร

logo.png
ชีวิตนี้ยังหนีไม่พ้น Microsoft จริงๆ เพราะตอนนี้ Microsoft ได้ออก Node.js Tools for Visual Studio (ณ วันนี้ก็ version 1.2 แล้ว) ซึ่งเป็น Extension เสริมที่ทำให้ Visual Studio(ตัวเต็ม) นั้นทำงานกับ Node ได้อย่างมีประสิทธิภาพมากขึ้นซึ่งสามารถใช้ได้กับ VS2015 – Official Link

พอลงไปแล้วก็จะมี Node.js Tools โผล่มาตรงนี้

node_tool

จากที่ Microsoft โปรโมทก็มีคร่าวๆ ดังนี้

Project Templates

ซึ่งทำให้เราสร้าง Project โดยเลือกได้เลยว่าจะเอา โปรเจคเปล่าๆ หรือมาพร้อมกับ Code ตัวอย่างที่เขียน http server ง่ายๆ ถ้ากลัวเริ่มไม่ถูก

templates
เห็นว่ามี templates ให้เลือกเต็มเลย

IntelliSense

ซึ่งผมลองแล้วก็บอกได้ว่า สมตามที่โฆษณาไว้ เพราะมันมี icon แสดงให้ดูง่ายและเร็วด้วย (สำหรับ Build-in Function นะครับ ถ้าเป็น module ที่เราใช้อาจจะต้องไปใช้ TypeScript เหมือนให้มี IntelliSense)
intellisense.png

Npm Integration

มีหน้าจอที่เป็น UI ให้ใช้ในการหา module ต่างๆ ได้ง่ายขึ้นสำหรับคนที่ไม่สันทัด command line

npm_1.png
เวลา Right Click ที่ npm folder ใน Project
npm_2
พิมพ์ “mocha” ไปก็มี version ต่างๆให้เลือก (แต่ผมว่าใช้ commandline เร็วกว่านะ :p )

Interactive Window

เป็นหน้าต่างที่เอาไว้ลอง Code JavaScript แบบทันทีทันใจแถมยังมี syntax Hilight กับ IntelliSense ให้ด้วย

interact_win
เปิดจากตรงนี้
interact_win2
หน้าต่างเปิดมาเป็นแบบนี้
interact_win3
ลองพิมพ์ function บวกเลขไปดูครับ ขึ้น Undefined…
interact_win4
ลองใส่ add(1,2) ดู ก็จะได้คำตอบออกมาเป็น “3”

Advanced debugging

ใช้ในการ Debug เช่น การตั้ง break points หรือการใช้งานพวก Watch ในการดูค่าตัวแปรต่างๆ ซึ่งทำได้ดีมากเหมือน C# ตรงนี้ผมว่า Powerful จริง

debug
ยกตัวอย่างมี express app ตัวนึงรับ ‘GET’ request มาครับ

จะเห็นว่าเราเห็นค่าของตัวแปร req ทั้งหมดเลย

debug_2
req.headers เราเห็นหมด ง่ายๆแบบนี้ (y)

 

และอื่นๆอีกมากมาย เช่น Profiling (ตัวนี้เด็ดมากกกก), Unit Testing, TypeScript Integration

ปล. ตอนแรกว่าจะเขียนเรื่อง Profiling แต่เห็น Features อื่นก็น่าสนใจไม่น้อยเลยเอามาเขียนก่อนครับ 😉

รู้จักกับ Modern Agile – agile 2016 ;)

logo.png

 

เป็นที่รู้กันว่า Agile นั้นถูกใช้งานอย่างแพร่หลายใน Software Development ซึ่งแนวคิดของ Agile นั้นมีการพูดถึงตั้งแต่ปี 2001 แต่มาถึงปีนี้ 2016 ทาง Agile Alliance(สมาพันธ์แห่งอไจล์ :p) ก็ได้พูดถึงสิ่งที่เรียกว่า Modern Agile โดยมีแนวคิดสำคัญ 4 อย่างที่ คาดหวังว่าจะช่วยจะทำให้เกิดผลลัพท์และสร้าง Culture ที่ดีแบบเหนือความคาดหมาย!!!

  1. Make People Awesome – ทำให้ทุกคนรู้สึกยอดเยี่ยม
    สตีฟ จอบส์ เคยถามเพื่อนร่วมงานว่า “อะไรคือประโยชน์สูงสุดที่เราสามารถมอบให้ลูกค้าได้”
    ใน modern agile นั้น เราถามถึง “การทำยังไงให้ทุกๆคนที่เกี่่ยวข้องทั้งหมดที่เกี่ยวข้องรู้สึก awesome!”
    เราเรียนรู้ถึง User และจุดที่ User เจ็บปวดและควรแก้ไข แล้วก็ทำให้พวกเค้ารู้สึก awesome!
  2. Make Safety a Prerequisite – ปลอดภัยไว้ก่อน
    ความปลอดภัยไว้ก่อนทั้งความต้องการพื้นฐานของมนุษย์และหัวใจสำคัญที่จะทำให้เกิดประสิทธิภาพสูงสุด ซึ่งเป็นสิ่งที่เราควรจะต้องมีเช่น เวลา การให้ข้อมูล ความเคารพหรือเชื่อใจกันและกัน การเงิน สุขภาพ และความสัมพันธ์ของคนฝ่ายต่างๆ
  3. Experiment & Learn Rapidly – ทดลองและเรียนรู้อย่างรวดเร็ว
    เราไม่สามารถทำให้คนรู้สึก awesome หรือ make safety a prerequisite ได้ถ้าเราไม่เรียนรู้ และที่สำคัญเราต้องเรียนรู้อย่างรวดเร็วโดยการทดลองบ่อยๆ เราต้องทำให้รู้สึกว่าความล้มเหลวในการทดลองเรียนรู้ไม่ได้เป็นเรื่องแย่อะไร ซึ่งจะเป็นตัวช่วยให้มีการลองอะไรใหม่ๆมากขึ้น
  4. Deliver Value Continuously – ส่งมอบสิ่งที่มีคุณค่าอย่างต่อเนื่อง
    ถ้าไม่มีการ deliver อะไรเลยก็จะไม่ช่วยให้ใครรู้สึก awesome ใน modern agile นั้นเราถามตัวเองว่า “เราจะทำอย่างไรให้เราสามารถ deliver สิ่งที่เป็น valuable work ได้เร็วขึ้น”
    การที่จะ deliver งานที่มีคุณค่าได้อย่างต่อเนื่องนั้น เราจะต้องทำการแบ่งส่วนงานที่ใหญ่ให้เป็นส่วนเล็กๆที่ยังมีคุณค่า เพื่อที่จะทำให้การ deliver นั้นเร็วขึ้น

เรามาเริ่มทำให้ทุกๆคนรอบตัวเรา AWESOME กัน!!

References: