cc :: somkiat

ช่วงนี้มีโอกาสมาเขียนและ review code ที่พัฒนาด้วย React กันนิดหน่อย ปัญหาหลักที่พบเจอคือ การออกแบบ react component สำหรับระบบงาน ในแต่ละ component ทำงานมากเกินไป ในแต่ละ component reuse ได้ยาก ในแต่ละ component ทดสอบได้ยาก ดังนั้นเรามาเข้าใจกับการออกแบบ component ที่น่าจะดีกันหน่อย

จากการค้นหา พบว่ามีการอธิบายเรื่องเหล่านี้ไว้เยอะเลย

ยกตัวอย่างเช่น

เป้าหมายหลักคือ แยกหน้าที่การทำงานระหว่างการจัดการข้อมูลและการแสดงผลออกจากกัน นั่นคือ SRP (Single Responsibility Principle)

สามารถสรุปแนวคิดง่าย ๆ ไว้ดังนี้

Container หรือ Smart component มีหน้าที่สำหรับการจัดการข้อมูล บางครั้งเรียกว่า Stateful component
Presentation หรือ Dumb component มีหน้าที่สำหรับแสดงผลซึ่งถูกสั่งหรือส่งข้อมูลมาจาก Container เท่านั้น บางครั้งเรียกว่า Stateless component

มีอีกเรื่องที่สำคัญคือ ควรแยกส่วนของ business logic ออกไปจาก component ด้วยนะ แต่เรื่องนี้จะไม่อธิบายในส่วนนี้

มาถึงตรงนี้อาจจะนึกภาพตามไม่ออก

ดังนั้นมาดู code ตัวอย่างกันดีกว่า ตัวอย่างเช่น ส่วนการแสดง comment ทั้งหมดใน blog นี้ เรามักจะพบเจอ component หน้าตาแบบนี้ นั่นคือ รวมทุกอย่างไว้ในเพียง component เดียว หรือเรียกว่า Fat component ทำงานทั้งดึงข้อมูลจาก API มา และทำการแสดงผล ดังนี้ [gist id="66e023c87ac7bd71ec87d5e5da4e9180" file="CommentListWithFatComponent.js"] ผลที่ตามมาคือ CommentList เป็น React component ที่ไม่สามารถ reuse ได้เลย นั่นหมายความว่า ถ้าต้องการแสดงข้อมูล comment เหมือนกันแต่ข้อมูลมาจาก API อื่น ๆ จะไม่สามารถทำได้เลย แต่ถ้าสังเกตุจะพบว่า Component นี้ต้องการเพียงข้อมูลตามโครงสร้างที่ต้องการเท่านั้น จากตัวอย่างคือ Array นั่นเอง ดังนั้นจะดีกว่าไหม ถ้าเราทำการส่งข้อมูลเข้ามายัง component ผ่านทาง PropsType

ดังนั้นจะดีไหม ถ้าเราแยกส่วนการดึงข้อมูลไปไว้ที่ component อื่น

โดยเราเรียก component นี้ว่า Container ดังนี้ ส่วนที่ 1 คือ CommentListContainer ทำหน้าที่ดึงข้อมูลจาก API จากนั้นส่งข้อมูลไปยัง CommentList component ผ่านทาง PropsType [gist id="66e023c87ac7bd71ec87d5e5da4e9180" file="CommentListContainer.js"] ส่วนที่ 2 คือ CommentList component ทำหน้าที่แสดงผลข้อมูล comment ทั้งหมดออกมา จากข้อมูล comment ที่ส่งผ่านมายัง PropsType [gist id="66e023c87ac7bd71ec87d5e5da4e9180" file="CommentListWithDumbComponent.js"] ผลที่ตามมาคือ แยกการทำงานตามหน้าที่ที่ชัดเจน CommentList component นั้นสามารถ reuse ได้ง่าย CommentList component นั้นสามารถทดสอบด้วยข้อมูลรูปแบบต่าง ๆ ได้ง่ายทั้ง success และ fail case ยังไม่พอนะ ในส่วนของ CommentList นั้น เราสามารถแยกการแสดงผลของแต่ละ comment ออกมาเป็น Component ได้อีก มันจะแยกกันไปถึงไหน !! ตัวอย่าง source code อยู่ที่ Github::Up1::Comments

สุดท้ายแล้ว

ขอแนะนำให้สร้าง Presentation หรือ Dumb component ให้เยอะที่สุดเท่าที่จะทำได้ แล้วมันจะทำให้ผลที่ออกมา ต่างจากเดินอย่างมาก อยากให้ component แสดงข้อมูลอะไร ก็ส่งเข้าไป อยากให้ component ทำงานตาม event/action ที่เกิดขึ้นอย่างไร ก็ส่งเข้าไป ไม่เชื่อก็ลองดู

แต่ก็ใช่ว่าจะเหมาะไปกับทุกเรื่องนะ !!

ขอให้สนุกกับการ coding ครับ

ปล. ถ้าใครไม่สนใจเรื่อง reuse ก็ทำแบบเดิมกันต่อไปนะ

สังเกตุไหมว่า ? มีการสร้าง component ต่าง ๆ เยอะเหลือเกิน ดังนั้นปัญหาที่ตามมาคือ โครงสร้างของ project เรานั้นเอง ทำอย่างไรที่จะจัดการแล้วไม่งง ? ทำอย่างไรที่จะจัดการแล้วไล่ code ได้ง่าย ? การจัดการ action/event ของแต่ละ component ละ จะทำอย่างไรดี ?

ข้อมูลจาก TIOBE Index ในเดือนกรกฎาคม ปี 2560 นั้น พบว่าภาษา Go ได้ก้าวเข้ามาสู่ 10 อันดับแรก ของภาษาโปรแกรมที่ได้รับความนิยมสูงสุดเป็นครั้งแรก ซึ่งทำให้ภาษา Go เข้ามาเป็นหนึ่งในภาษาหลักของการพัฒนาโปรแกรมไปแล้ว

เมื่อนำมาเปรียบเทียบกับภาษา Java และ JavaScript

ส่วนภาษาโปรแกรมอื่น ๆ ที่มีความนิยมลดลง

ประกอบไปด้วย

JavaScript
Perl
Ruby
Assembly
Objective-C
Kotlin
Elixir

ส่วนพวกภาษาหลัก ๆ ก็ยังคงเหมือนเดิม ทั้ง Java, C, C++, Python, C# และ PHP แสดงข้อมูลดังนี้

โดยข้อมูลต่าง ๆ ก็สอดคล้องกับข้อมูลจาก Redmonk

วัดจากจำนวนของการ pull request ใน Github ซึ่งภาษา Go ก็มีจำนวนที่สูงแบบก้าวกระโดดเช่นเดียวกับภาษา TypeScript, R, Swift และ Rust แสดงดังรูป

ขอให้สนุกกับการ coding ครับ

ปัญหาที่พบเจอ

เมื่อใช้งาน Cobertura กับ Java 1.8 และ Apache Maven 3 จะเจอปัญหาที่ทำให้ไม่สามารถสร้าง report ได้ ซึ่งเกิด error message ดังนี้ [gist id="e5cbc18e50724f1c0a4b8bc14128f489" file="error.txt"]

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

สาเหตุที่เจอคือ cobertura maven plugin 2.6 นั้นใช้งาน cobertura 2.0.3 ภายในจะใช้งาน ASM 4.1 ซึ่งไม่สนับสนุน Java 8 ดังนั้นสิ่งที่ต้องทำคือ เปลี่ยน version ของ ASM ซะ ในการ build ซึ่งทำในไฟล์ pom.xml ของ Apache Maven ดังนี้ [gist id="e5cbc18e50724f1c0a4b8bc14128f489" file="pom.xml"]

ปล. แก้ไขปัญหานี้ง่าย ๆ ด้วยการใช้งาน cobertura maven plugin 2.7 นะครับ

โดยเครื่องมือที่คล้าย ๆ กันเช่น Jacoco ก็มีปัญหาเช่นเดียวกัน

ช่วงนี้ลองศึกษาภาษาโปรแกรมใหม่ ๆ เล่นดูบ้าง หนึ่งในนั้นคือ ภาษา Elm ซึ่งมีความสามารถที่น่าสนใจ เช่น

JavaScript Interop
No runtime exception (อันนี้น่าสนใจมาก ๆ)
Great performance
Enforced somatic versioning

ดังนั้นลองมาเรียนรู้ภาษา Elm ด้วยแนวทาง TDD กันหน่อยดีกว่า

เริ่มต้นด้วยการติดตั้ง

สามารถทำการติดตั้งง่าย ๆ แต่ละ OS ได้ที่ Install Elm หลังจากที่ติดตั้งแล้ว จะมีชุดคำสั่งให้ใช้ดังนี้

elm-repl (Read Eval Print Loop)
elm-reactor
elm-make
elm-package

เป้าหมายของการเรียนรู้ ประกอบไปด้วย สร้าง project อย่างไร ? จะพัฒนาระบบด้วยการเขียน Test ทำอย่างไร ?

โดยใช้โจทย์สุด classic คือ FizzBuzz การทดสอบจะใช้ package ชื่อว่า elm-test เพราะว่า มันสวยและง่ายดี ที่สำคัญชอบรูปแบบการใช้งานนั่นเอง มาเริ่มกันเลย

ขั้นตอนที่ 1 สร้าง project กัน

ในการสร้าง project ด้วยคำสั่ง [gist id="44c5df38006c8f37da1b9996ca96c4ab" file="step01.txt"] ผลที่ได้คือ โครงสร้างของ project เป็นดังรูป

แน่นอนว่า มี folder src สำหรับเก็บ production code มี folder tests สำหรับเก็บชุดการทดสอบนั่นเอง โดยจะมีตัวอย่างของชุดการทดสอบให้ด้วย จากนั้นทำการ run test ด้วยคำสั่ง [gist id="44c5df38006c8f37da1b9996ca96c4ab" file="step02.txt"] เพียงเท่านี้เราก็สามารถเริ่มเรียนรู้ การพัฒนาระบบด้วยภาษา Elm กันได้แล้ว ปล. ถ้าสังเกตุจะเห็นว่ามี link สำหรับการเขียน test ให้ด้วยนะ !!

ขั้นตอนที่ 2 มาเขียน test แรกกันดีกว่า

โดยจะทำการสร้างไฟล์ชื่อว่า FizzbuzzSpec.elm ขึ้นมา เขียน test case ได้ดังนี้ [gist id="44c5df38006c8f37da1b9996ca96c4ab" file="test01.elm"] จากนั้นทำการ run test จะได้ผลการทดสอบดังนี้ [gist id="44c5df38006c8f37da1b9996ca96c4ab" file="test01.txt"] คำอธิบาย เกิด error ขึ้นมาเนื่องจากหา variable ชื่อว่า say ใน module ต่าง ๆ ไม่เจอ นั่นคือการบอกว่า เราต้องสร้าง module ที่มี variable ชื่อว่า say ขึ้นมา เพื่อรับค่า 1 เข้าไป จากนั้นทำการ return "1" ออกมา

ขั้นตอนที่ 3 ทำการสร้าง module ใหม่ชื่อว่า Fizzbuzz อยู่ใน folder src

ทำการสร้างไฟล์ชื่อว่า Fizzbuzz.elm ซึ่งจะมี function/method ชื่อว่า say ได้ดังนี้ [gist id="44c5df38006c8f37da1b9996ca96c4ab" file="Fizzbuzz01.elm"]

ขั้นตอนที่ 4 ทำการแก้ไขไฟล์ FizzbuzzSpec.elm ให้เรียกใช้งาน Fizzbuzz module

ด้วยการ import module เข้ามาดังนี้ [gist id="44c5df38006c8f37da1b9996ca96c4ab" file="test02.elm"] จากนั้นทำการทดสอบสิ ได้ผลการทดสอบดังนี้ [gist id="44c5df38006c8f37da1b9996ca96c4ab" file="step03.txt"] ผลการทดสอบคือ fail นั่นเอง เนื่องจากคาดหวังว่าต้องได้ผลลัพธ์คือ 1

ขั้นตอนที่ 5 ทำให้การทดสอบผ่านแบบง่ายสุด ๆ

เขียน code ได้ดังนี้ [gist id="44c5df38006c8f37da1b9996ca96c4ab" file="Fizzbuzz02.elm"] จากนั้นทำการ run test ได้ผลดังนี้ [gist id="44c5df38006c8f37da1b9996ca96c4ab" file="step04.txt"] ผลที่ได้คือผ่านแล้วววววว

ขั้นตอนที่ 6 ทำการสร้าง test case ที่สองคือ 3 จะพูดว่า Fizz

[gist id="44c5df38006c8f37da1b9996ca96c4ab" file="test03.elm"] ผลการทดสอบไม่ผ่านแน่นอน แสดงดังนี้ [gist id="44c5df38006c8f37da1b9996ca96c4ab" file="step05.txt"]

ขั้นตอนที่ 7 มาเขียน code เพื่อให้ test ผ่านกันอีกรอบ

การแก้ไขปัญหามีหลายแบบ แล้วแต่จะเลือก โดยผมเลือกใช้ case expression ดังนี้ [gist id="44c5df38006c8f37da1b9996ca96c4ab" file="Fizzbuzz03.elm"]

ขั้นตอนที่ 8 ทำการเขียน test และเขียน code เพื่อให้ test ผ่านกันต่อไป

นั่นคือ case 5 จะพูดว่า Buzz สามารถเขียน code เพื่อแก้ไขปัญหาได้ดังนี้ [gist id="44c5df38006c8f37da1b9996ca96c4ab" file="Fizzbuzz04.elm"] นั่นคือ case 15 จะพูดว่า FizzBuzz สามารถเขียน code เพื่อแก้ไขปัญหาได้ดังนี้ [gist id="44c5df38006c8f37da1b9996ca96c4ab" file="Fizzbuzz05.elm"] ตัวอย่างของ source code ทั้งหมดอยู่ที่ Github :: Learn Elm

มาถึงตรงนี้ก็พอจะทำให้ผมสามารถเริ่มต้นเรียนรู้ภาษา elm

แบบงู ๆ ปลา ๆ ได้บ้างแล้ว จากนี้ก็ลองไปศึกษาส่วนอื่น ๆ กันต่อไป ขอให้สนุกกับการ coding นะครับ

เป็นคำถามที่ฟังดูแล้ว ไม่น่าจะมีอะไรเลย คือ งานของ Developer เสร็จตอนไหน ?

คำตอบง่าย ๆ คือ ก็ตอนเขียน code เสร็จไงล่ะ !!

มาดูสิ่งที่เกิดขึ้นกับทีมที่ 1

ปกติในทุก ๆ งานนั้น จะเผื่อเวลาไว้ประมาณ 1-3 เดือน สำหรับการทดสอบและเตรียมทุกสิ่งอย่างก่อนจะ release ระบบ ดังนั้น developer ก็ต้องเขียน code ให้เสร็จหรือ freeze code ก่อน จากนั้นก็ส่งให้ทาง QA/Tester ทำการทดสอบแบบเต็ม ๆ หลังจากนั้นอีกสักสัปดาห์ต่อมา ถ้าทุกอย่างมันทำงานได้ดี ก็จะไม่มีเสียงกรีดร้องอะไร แต่โชคไม่ค่อยดีเท่าไร ที่มักจะมีเสียงกรีดร้องออกมายัง developer เช่น ระบบทำงานไม่ถูกต้อง ระบบพัง ระบบ ...

ดังนั้น งานที่ developer บอกว่าเสร็จ มันเสร็จจริง ๆ ไหม ?

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

โชคไม่ดีนัก เรามักจะอยู่ในทีมที่ทำงานกันแบบนี้ !!

มาดูสิ่งที่เกิดขึ้นกับทีมที่ 2

ทีมนี้ไม่มี QA/Tester ด้วย นั่นหมายความว่า developer ก็ต้องทำการทดสอบเองนะ ดังนั้นไม่มีการ freeze code เพื่อทดสอบและเตรียมพร้อม 3 เดือนอีกแล้วนะ เนื่องจากเขียนเอง ทดสอบเอง ใช้เวลาไม่เกิน 1-3 ชั่วโมงก็ freeze code เพื่อทดสอบได้แล้ว ยิ่งไปกว่านั้นทีมนี้ก็ทำการ deploy code ที่เขียน ขึ้นไปยัง production server ที่ผู้ใช้และลูกค้าใช้งานด้วย เพื่อทำให้มั่นใจว่า งานที่ทำขึ้นมามันเสร็จจริง ๆ นั่นหมายความว่า งานของ developer จะเสร็จก็ต่อเมื่อสิ่งที่เขียนขึ้นมานั้น ไปอยู่ต่อหน้าลูกค้าจริง ๆ ลูกค้าได้ใช้งานจริง ๆ

จะเห็นได้ว่า ทั้งสองทีมมีความแตกต่างกันมากจริง ๆ

เนื่องจากมีคำจำกัดความ ของคำว่าเสร็จแตกต่างกัน

code ที่เขียนขึ้นมาจะไร้ค่ามาก ๆ ถ้ายังไม่ถึงมือลูกค้า ถึงแม้จะถึงมือลูกค้าแล้ว แต่ไม่สามารถสร้างรายได้อะไรให้บริษัทเลย มันก็ไร้ค่าเช่นกัน เนื่องจากบริษัทก็ไม่มีเงินมาจ่ายเงินเดือนให้ developer เช่นกัน

ดังนั้น developer ต้องให้ความสนใจและใส่ใจ ต่อสิ่งที่สร้างขึ้นมา จนกว่าจะถึงมือลูกค้า

เป็นทัศนคติที่ developer ที่ดีควรมีติดตัวไว้เสมอ เพื่อสร้าง code ที่ดีออกมา เพื่อปรับปรุง code ให้ดียิ่งขึ้น ไม่ใช่เขียน code ให้เสร็จไปวัน ๆ แล้วรอวันเงินเดือนออก แล้วรอวันได้ bonus แล้วรอวันได้เงินเดือนขึ้น แน่นอนว่าองค์กรก็ต้องเอื้อต่อการทำงานด้วยเช่นกัน

วันนี้คำว่าเสร็จของ developer คืออะไรกันบ้าง ?

ขอให้สนุกกับการ coding ครับ

ทางธนาคารแห่งประเทศไทย หรือ Bank Of Thailand (BOT) ได้เปิด BOT APIs ให้บริการข้อมูลต่าง ๆ ที่น่าสนใจดังนี้

อัตราแลกเปลี่ยน จำนวน 8 APIs
อัตราดอกเบี้ย จำนวน 12 APIs
ผลการประมูลตราสารหนี้ จำนวน 1 API

ดังนั้นมาลองใช้งานกันหน่อย ว่าเป็นอย่างไรบ้าง ? ใช้งานยากหรือง่ายอย่างไร ? ในมุมมองของนักพัฒนาคนหนึ่ง

รายละเอียดทั่วไปของ API

BOT APIs เป็น REST APIs โดยข้อมูลอยู่ในรูปแบบ JSON (JavaScript Object Notation) ในแต่ละ API นั้นมีเอกสารอธิบายชัดเจน ตัวอย่างเช่น

คำอธิบาย
ความถี่ในการเปลี่ยนแปลงข้อมูล
เวลาในการเผยแพร่
ที่มาของข้อมูล
รายละเอียดเพิ่มเติม
API endpoint
Parameter ต่าง ๆ ที่จำเป็น ทั้งชื่อ ชนิดข้อมูล และ ตัวอย่าง
ข้อมูล parameter ที่จะได้รับ ฟังดูแล้วแปลก ๆ น่าจะเป็นข้อมูลที่ได้รับน่าจะเข้าใจง่ายกว่า !!
ตัวอย่างข้อมูล ในส่วนนี้ง่ายยากมาก น่าจะจัดรูปแบบให้ง่ายง่าย ๆ หน่อย
มีตัวอย่างการเขียน code ใช้งานทั้ง JavaScript และ Python แต่น่าจะใส่ format code ส่วย ๆ หน่อยนะ

ในส่วนนี้นักพัฒนาก็เขียน library ใช้งานสำหรับภาษาต่าง ๆ กันไหม ?

ตัวอย่างของข้อมูลที่ได้จาก API อัตราแลกเปลี่ยนถัวเฉลี่ยถ่วงน้ำหนักระหว่างธนาคาร (รายวัน)

[gist id="fc04612cb4a4231d3b6294d008304d93" file="result.json"]

มาดูโครงสร้างของข้อมูลกันหน่อย

ซึ่งดูแล้วข้อมูลไม่จำเป็นเยอะน่าดู แต่คงเป็นเรื่องความน่าเชื่อถือของข้อมูล !! APIs ต่าง ๆ จะส่ง response code เป็น 200 กลับมาเสมอ โดยผู้ใช้บริการสามารถตรวจสอบผลการทำงาน ผ่านข้อมูลใน result.success ว่าเป็น true หรือ false

true คือ ผลการทำงานถูกต้อง
false คือ ผลการทำงานไม่ถูกต้อง เช่น parameter ที่ส่งไปไม่ถูกต้อง

จากตัวอย่างข้างต้น เป็นผลการทำงานที่ถูกต้อง ดังนั้นข้อมูลของอัตราแลกเปลี่ยนจะอยู่ใน result.data ยังไม่พอในข้อมูลยังแบ่งออกเป็น 2 กลุ่มคือ

data_header สำหรับคำอธิบายต่าง ๆ เช่นแหล่งที่มา และ วันเปลี่ยนแปลงล่าสุด
data_detail สำหรับข้อมูลจริง ๆ

สิ่งที่น่าสนใจคือ ข้อมูลที่มีจุดทศนิยมจะมีจำนวน 7 หลักทั้งหมด !!

ในส่วนการทำงานผิดพลาด

จะมีผลการทำงานมาอยู่ที่ result.error แทน ดังตัวอย่างใส่ข้อมูลวันที่ของ start_period ผิดรูปแบบที่กำหนด [gist id="fc04612cb4a4231d3b6294d008304d93" file="error.json"] โดยในส่วนของ error code ไม่มีอธิบายไว้ในหน้า website

ถ้าไม่ใส่ api-key หรือใส่ผิด ใน HTTP Header จะไม่มี error code
es001 คือ ไม่ใส่ข้อมูล เช่น Parameter: start_period must not be null
es002 คือ ข้อมูลวันเริ่นต้นอยู่หลังวันสิ้นสุด เช่น Parameter start_period must not be greater than end_period
es003 คือ รูปแบบข้อมูลผิด เช่น Parameter: start_period format must be yyyy-mm-dd

สุดท้ายแล้ว BOT API เป็นแหล่งข้อมูลที่น่าสนใจ

สามารถนำไปใช้ประโยชน์กันได้ดีเลยและน่าเชื่อถือได้ ปล. อย่าลืมอ่านเงื่อนไขการใช้บริการด้วยนะครับ ยกตัวอย่างเช่น

ธนาคารแห่งประเทศไทยจะไม่รับผิดชอบต่อ ความถูกต้อง และความล่าช้าของข้อมูล
ยกเลิกการให้บริการข้อมูล BOT API ของธนาคารแห่งประเทศไทยแก่ผู้ใช้บริการเมื่อใดก็ได้
ผู้ใช้บริการยอมรับและตระหนักดีว่าธนาคารแห่งประเทศไทยจะไม่รับผิดชอบในความเสียหายใด ๆ ที่เกิดขึ้นหรืออาจเกิดขึ้นกับผู้ใช้บริการ จากบริการข้อมูล BOT API ของธนาคารแห่งประเทศไทย ไม่ว่าโดยเหตุประการใด

Reference Websites https://iapi.bot.or.th/Developer?lang=th

เก็บตกจากการไปฟังเรื่อง GraphQL จากงาน CNX Meetup ที่เชียงใหม่ พบว่ามีหลายสิ่งอย่างที่น่าสนใจ พบว่ามีหลายสิ่งอย่างที่ชวนสงสัย หนึ่งในนั้นคือ GraphQL vs. REST ว่ามันเหมือนหรือแตกต่างกันอย่างไร ดังนั้น จึงทำการสรุปแบบกว้าง ๆ ไว้นิดหน่อย

เริ่มต้นกับ GraphQL

เป็นแนวคิดใหม่ ๆ ของการพัฒนาระบบ APIs ให้สะดวกมากยิ่งขึ้น แทนที่จะกำหนด Endpoint มากมายขึ้นมาตาม resources ก็ให้มีเพียง Endpoint เดียว จากนั้นก็ส่ง query เข้าไปเพื่อใช้งาน ส่งผลให้ทีม frontend และ backend ทำงานด้วยกันและใกล้ชิดกันมากขึ้น แต่ก็ยังทำการส่งและรับข้อมูลอยู่บน HTTP protocol เช่นเดิม รวมทั้งยังใช้แนวความคิดต่าง ๆ จาก REST อยู่

มาดูเรื่องแรกคือ Resources

หัวใจหลักของ REST คือ resource โดยแต่ละ resource จะมี endpoint แยกตาม HTTP method ตัวอย่างเช่น การเข้าถึง resource ชื่อว่า employee ด้วย HTTP GET จะส่งข้อมูลของ employee ในรูปแบบ JSON กลับมา ซึ่งข้อมูลประกอบไปด้วย

รายละเอียดของ employee
รายละเอียดของ department ที่อยู่

ดังนี้ [gist id="b68e938aa9e85fdeb5e267cf5af10a2a" file="1.txt"] ทุก ๆ ครั้งที่เรียกใช้งานผ่าน Endpoint ของ resource employee จะทำการส่งข้อมูลในรูปแบบนี้กลับมาเสมอ แต่ GraphQL มีข้อแตกต่างออกไป คือ จะทำการกำหนดชนิดของข้อมูลออกเป็น 2 ส่วน (เช่นเดียวกับ REST) ซึ่งมีความสัมพันธ์ตามที่กำหนด มันก็คือการกำหนด resource นั่นเอง จากตัวอย่างกำหนดแบบ 2 ทิศทางคือ 1. แต่ละ Employee จะมีข้อมูล Department 2. แต่ละ department จะมี list ของ employee [gist id="b68e938aa9e85fdeb5e267cf5af10a2a" file="2.txt"] จากนั้น resource หรือ endpoint นี้ของ GraphQL สามารถทำการกำหนดรูปแบบของการ query หรือดึงข้อมูลตามที่ client หรือผู้ใช้งานต้องการได้ ซึ่งเป็นข้อแตกต่างจาก REST !! ที่ข้อมูลจะถูกระบุไว้อยู่แล้ว (เพิ่มหรือลดไม่ได้) สามารถทำการกำหนดการ query ด้วย GraphQL Schema ดังนี้ [gist id="b68e938aa9e85fdeb5e267cf5af10a2a" file="3.txt"] ดังนั้นผู้ใช้งานสามารถส่ง query เข้ามายัง GraphQL ได้ตามที่ต้องการ ยกตัวอย่างเช่น การดึงข้อมูลของ employee ที่มี id=1 ต้องการข้อมูลในรูปแบบที่แตกต่างกันดังนี้ [gist id="b68e938aa9e85fdeb5e267cf5af10a2a" file="4.txt"] มาถึงตรงนี้น่าจะพอทำให้เก็นความแตกต่างเล็กน้อย แต่ว่ามีประโยชน์มาก ๆ สำหรับผู้เรียกใช้งานแล้วนะ เช่น ลดจำนวน Endpoint ของ APIs ลงไป ลดขนาดข้อมูลของ response ลงไปได้เยอะ ปรับเปลี่ยนรูปแบบข้อมูลตามความต้องการของผู้ใช้งาน

ปล. เห็นนรกของฝั่งที่พัฒนา APIs ด้วย GraphQL กันบ้างไหม ?

มาดูเรื่องที่สองคือ URL Endpoint หรือ Routing

ในส่วนของ REST นั้นจะมีการกำหนด URL Endpoint ไว้ในรูปแบบดังนี้ GET /employee/:id POST /employee/:id PUT /employee/:id GET /department/:id ซึ่งแยกตาม resource และ HTTP Method กัน แต่สิ่งที่ยากขึ้นมานิดหน่อย คือ จะเรียกใช้งานอย่างไร แน่นอนว่า REST APIs เหล่านี้ก็ต้องมีเอกสารอธิบายการใช้งาน รวมทั้งรูปแบบของ request และ response อีกด้วย ใน GraphQL นั้นไม่ได้ใช้ URL Endpoint เหมือนกับ REST แต่ใช้สิ่งที่เรียกว่า GraphQL Schema ซึ่งทำการกำหนดผ่าน type 2 ชนิดคือ

Query สำหรับการดึงข้อมูล
Mutation สำหรับการเพิ่มและแก้ไขข้อมูล

ยกตัวอย่างดังนี้ [gist id="b68e938aa9e85fdeb5e267cf5af10a2a" file="5.txt"] โดยใน request เดียวสามารถส่งการ query ได้มากกว่าและซับซ้อนได้ หรือจะทำการเพิ่มหรือแก้ไขข้อมูลก็ได้ ซึ่งลดจำนวนการเรียกใช้งาน APIs ลงไป แถมไม่ต้องไประบุด้วยอีกว่าต้องใช้ HTTP GET, POST, PUT หรือ DELETE เนื่องจากได้เปลี่ยนวิธีการด้วยการส่ง keyword ใหม่ไปนั่นเอง [code] query { … } mutation{ ... } [/code] มองง่าย ๆ คือ GraphQL นั้นคือ endpoint ที่ทำการเรียกหลาย ๆ Endpoint ของ REST นั่นเอง เป็นข้อดีอย่างมากของ GraphQL แสดงดังรูป รูปมันคุ้น ๆ เหมือนกับ API Gateway ยังไงก็ไม่รู้นะ !!

โดยสรุปแล้ว

REST และ GraphQL นั้นไม่ได้แตกต่างกันมากนัก มีพื้นฐานมาจากเรื่องที่คล้ายหรือใกล้เคียงกัน แต่สิ่งที่แตกต่างเพียงเล็กน้อยของ GraphQL นั้น กลับช่วยทำให้เกิดความเปลี่ยนแปลงในการสร้างและใช้งาน APIs มากมาย GraphQL นั้นช่วยลดจำนวน APIs endpoint ลงไป ช่วยทำให้ผู้ใช้งานสะดวกยิ่งขึ้น ช่วยลดข้อมูลที่ไม่จำเป็นลงไปได้ ตามความต้องการของผู้ใช้งาน แต่ก็ได้เพิ่มเรื่องของการ query ที่ซับซ้อนขึ้นมา ถ้าระบบ APIs ของเราเป็น REST อยู่แล้ว มันก็ง่ายมาก ๆ สำหรับการปรับเปลี่ยนหรือเพิ่ม GraphQL ขึ้นมา ปล. น่าจะพอเห็นว่าการพัฒนา APIs ด้วย GraphQL มันน่าสนุกเพียงใด ถ้าทีม frontend และ backend ไม่คุยกัน หรือ ทำงานด้วยกัน ผมเชื่อว่า นรกกินหัวแน่นอนครับ ขอให้สนุกกับการ coding ครับ Reference Websites https://dev-blog.apollodata.com/introducing-explore-graphql-e71e5fda4e1a https://dev-blog.apollodata.com/graphql-vs-rest-5d425123e34b https://dev-blog.apollodata.com/why-graphql-is-the-future-3bec28193807 https://medium.com/@scbarrus/graphql-is-the-king-long-live-the-king-r-i-p-rest-cf04ce38f6c

ปัญหามีอยู่ว่า

ไม่สามารถทำการเขียน code เพื่อทำ UI Testing สำหรับ UISlider ที่มีการแก้ไขรูปแบบการแสดงผลได้

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

วิธีการแก้ไข

โดย UISlider แบบปกตินั้น สามารถสั่งให้เลื่อนค่าใน UISlider ได้ผ่าน method adjust() ดังนี้ [code] app.sliders["id"].adjust(toNormalizedSliderPosition: 0.05) [/code] แต่เมื่อเจอของจริง ๆ มันไม่ได้ เนื่องจากทำการหมุนไปทิศทางอื่น ๆ ดังนั้น จึงเริ่มทำความเข้าใจกับการทำงานของ method adjust() ก่อน ด้วยการเขียน extension ดังนี้ [gist id="940dccb99e41c272e5bdb00f887fcab3" file="1.swift"] เรียกใช้งานแบบนี้ ซึ่งทำงานได้เหมือนกัน แสดงว่าน่าจะเดินมาในทางที่น่าจะถูก !! [code] app.sliders["id"].adjustX(toNormalizedSliderValue: 0.05) [/code] จากนั้นก็เริ่มไปทดสอบกับ UISlider ในรูปแบบอื่น ๆ ทั้งการหมุนมุมต่าง ๆ เช่น

90 องศาทั้งบวกและลบ
180 องศา

แสดงค่าเริ่มต้นดังรูป

จากการศึกษาและทดลองของการหมุนในแต่ละรูปแบบ ก็มีการคำนวณที่แตกต่างกัน ทั้งแกนที่ใช้งานคือ แกม x และแกน y รวมทั้งจุดเริ่มต้นของ Thumb ว่าอยู่ตรงไหนอีกด้วย และจุดที่ต้องการให้เลื่อนไป โดยค่า default มีค่าตั้งแต่ 0 ถึง 1 โดยอีก 3 แบบสามารถเขียน code เพื่อควบคุม UISlider ได้ตามความต้องการ ซึ่งใส่จากซ้ายไปขวา และ บนลงล่างดังนี้ [gist id="940dccb99e41c272e5bdb00f887fcab3" file="2.swift"] ตัวอย่างของ source code อยู่ที่ Github :: Up1 ขอให้สนุกกับการ coding ครับ Reference Websites http://masilotti.com/ui-testing-cheat-sheet/

หลังจากงาน Google IO 2017 มีการโชว์ของต่าง ๆ เกี่ยวกับการทดสอบ Android app ตัวอย่างเช่น

Multiprocess Espresso
Android Test Orchestrator

เป็นความสามารถอยู่ใน Android Testing Support Library (ATSL) 1.0 ซึ่งตอนนี้ได้ปล่อยออกมาให้ใช้งานกันแล้ว ดังนั้นมาดูกันว่ามีความสามารถอื่น ๆ อะไรบ้าง รวมทั้งมาลองใช้งานกันดู

เริ่มด้วย Espresso มีการปรับปรุงเยอะเลย

ทำการปรับ version ใหม่เป็น Espresso 3.0 โดยความสามารถใหม่ ๆ ที่น่าสนใจมากคือ Multiprocess Espresso ทำให้สามารถ run แยก process การทดสอบออกจาก process default ได้ แต่ใช้ได้เฉพาะกับ Android O (API 26) ขึ้นไป ส่วนที่ต่ำกว่าก็ยังทำงานเช่นเดิม ส่วนการเขียน code สำหรับการทดสอบ Android app ด้วย Espresso ยังคงเหมือนเดิม เนื่องจากเป็นการเปลี่ยนแปลงภายในเท่านั้น ซึ่งจะมีประโยชน์มาก ๆ สำหรับ app ที่มีขนาดใหญ่ แน่นอนว่าต้องเขียนชุดการทดสอบด้วย Espresso นะเออ !! การทำงานเป็นดังรูป

ถึงตรงนี้ผมก็ยังไม่รู้ว่ามีประโยชน์อะไรชัดเจน !! เพราะว่ายังไม่เข้าใจมากนัก ดังนั้นมันต้องลองใช้งานดู

เริ่มด้วยต้องเปลี่ยนไปใช้ Google Maven Repository ก่อนนะ และทำการเพิ่ม dependency เป็น Espresso 3.0 ดังนี้ [gist id="15de4dcfbc8360af3f2b1f668d837da0" file="build.gradle"] จากนั้นทำการสร้างไฟล์ AndroidManifest.xml ใน folder /app/src/androidTest เพื่อทำการกำหนดค่าต่าง ๆ ในการทดสอบ app ด้วย Multiprocess Espresso [gist id="15de4dcfbc8360af3f2b1f668d837da0" file="AndroidManifest.xml"] ส่วนการเขียน code ยังคงเหมือนเดิม ตรงนี้นักพัฒนาสบายใจได้

เพิ่ม Grant Permission Rule เข้ามาให้แล้ว

ตั้งแต่ Android M (API 23) ขึ้นมา เปิดให้ app ทำการขอ permission ในขณะ runtime ได้ ดังนั้นในการทดสอบแบบเดิม ถ้าเจอการขอ permission แบบนี้แล้ว การทดสอบ fail แน่ ๆ ดังนั้น Espresso 3.0 จึงได้ทำการเพิ่ม GrantPermissionRule เข้ามา เพื่อยกเลิก dialog ของการขอ permission ในขณะทดสอบออกไป นั่นคือการจำลองว่า ผู้ใช้งานอนุญาตนั่นเอง !!

Android Test Orchestrator (Beta version)

โดยปกติการทดสอบผ่าน AndroidJUnitRunner นั้น จะทำการ run ทุก ๆ testcase ใน process เดียวกัน ดังนั้นทำให้เกิดปัญหามากมายตามมา เช่น

หยุดการทดสอบเมื่อเกิดปัญหา
มีการ share resource ต่าง ๆ เช่น ข้อมูลและสถานะต่าง ๆ ใน memory

ดังนั้น Android Test Orchestrator จึงมีเป้าหมายเพื่อแยกการทดสอบออกจากกัน ดังนั้นจึงต้องระมัดระวังด้วยว่า app ของเรานั้นมีการ share ข้อมูลต่าง ๆ หรือไม่ มิเช่นนั้นการทดสอบจะพังได้แบบง่าย ๆ การใช้งานต้องสั่งผ่าน command line นะ สามารถดูเพิ่มเติมได้ที่ Android Test Orchestrator แสดงผลการทำงานดังรูป

มีของใหม่ก็ต้องมีของที่ถูกเอาออกไป นั่นคือ Idling Resources

ซึ่งการเขียนส่วนใหญ่จะต้องทำการ custom และส่งผลให้ Espresso ทำงานได้แย่มาก ๆ ดังนั้นใน Espresso 3.0 จึงได้นำออกไป และสร้างสิ่งใหม่ขึ้นมาที่มีประสิทธิภาพดีกว่าเดิมคือ Idling concurrent ดังนั้นถ้าใครยังใช้พวก CountingIdlingResource อยู่ก็ตามไปแก้ไขกันเอาเองนะ

รวมทั้งเรื่องการทดสอบกับ ContentProvider

ก็ทำการเปลี่ยนจาก ProviderTestCase2 ไปเป็น ProviderTestRule ซึ่งเป็นชื่อในรูปแบบเดียวกับส่วนอื่น ๆ เช่น ActivityTestRule เป็นต้น

อ่านเพิ่มเติมได้ที่ Android Testing

Reference Websites https://android-developers.googleblog.com/2017/07/android-testing-support-library-10-is.html

อ่านเจอบทความเกี่ยวกับการเปลี่ยนระบบ search engine ของ Yelp มาใช้ Elasticsearch Moving Yelp's Core Business Search to Elasticsearch โดยที่ระบบเดิมนั้น ทำการ custom จาก Apache Lucene มากมายเช่น

Distributed Lucene
Master-slave
Custom text analysis สำหรับภาษาต่าง ๆ
Custom ระบบ ranking ของการค้นหาให้เป็นไปตาม business model เช่น การ review, เวลาเปิดปิด และตำแหน่งของร้าน เป็นต้น

สิ่งที่น่าสนใจคือ เหตุผลของการเปลี่ยนแปลงมาใช้ Elasticsearch ? จึงทำการแปลและสรุปไว้นิดหน่อย

1. ปัญหาเรื่อง Realtime indexing

เนื่องจากระบบเดิมนั้นมีโครงสร้างแบบ Master-Slave โดยที่ master server ทำหน้าที่สำหรับการ indexing data ส่วน slave นั้นทำหน้าที่สำหรับ query หรือดึงข้อมูล ข้อมูลจากการทำ indexing บน master นั้น จะถูก upload ไปไว้ที่ Amazon S3 จากนั้น slave จะทำการ download ข้อมูลจาก Amazon S3 มาตามเวลาที่กำหนดไว้ (Scheduler) เพื่อได้ข้อมูลใหม่มาใช้งาน ซึ่งทำให้เกิดปัญหากับบางระบบที่ต้องการข้อมูลแบบ realtime (ใช้คำว่าต้องรอไม่กี่วินาที) ตัวอย่างเช่น ระบบการจอง และ transaction ต่าง ๆ เป็นต้น การแก้ไขคือ นำ data store ที่ทำงานแบบ realtime มาใช้งานสำหรับงานนั้น ๆ ยกตัวอย่างเช่น Elasticsearch มาทำงานควบคู่กันไป โดยควบคุมการทำงานโดย application layer แต่ก็มีปัญหาเรื่องประสิทธิภาพการทำงานเมื่อระบบขยายใหญ่ขึ้น เนื่องจากทั้งการรวมและจัดเรียงผลการค้นหา ต้องทำในส่วน application layer !! (คอขวด)

2. ปัญหาเรื่อง ช้าต่อการเปลี่ยนแปลง

การทำงานนั้นจะมีทีมที่ทำหน้าที่ปรับปรุง ranking algorithm ของผลการค้นหา ซึ่งจะมีการเปลี่ยนแปลง code และ push code หลายครั้งต่อวัน จากนั้นจึงเข้าสู่กระบวนการ deploy แบบอัตโนมัติ แต่กว่าจะ rollout ได้แต่ละครั้งต้องใช้เวลานนาน โดยระบบการค้นหานี้เป็น microservice ที่ใหญ่ที่สุดของ Yelp แล้ว !! ที่สำคัญการ sharding ข้อมูลของการค้นหาจะแบ่งเป็น 2 ชั้นคือ (ข้อมูลใหญ่มาก ๆ) 1. Geosharding แบ่งจาก geolocation เช่นการแบ่ง business model แยกตามรัฐไปเลย 2. Microsharding /Microindex แบ่งโดยใช้ modulo (%) ตามจำนวนที่กำหนด ในแต่ละ instance จะมีการทำ indexing แยกกันไปอีก ดังนั้นหมายความว่า ถ้ามีการเปลี่ยนแปลงข้อมูลและ algorithm แล้ว ต้องทำการ update ในทุก ๆ instance !!! ส่งผลให้การเปลี่ยนแปลงแต่ละรอบต้องใช้เวลานาน ส่งผลต่อ business อย่างมากมาย จะปรับปรุงอย่างไรดี ?

3. ยากต่อการเพิ่ม feature ใหม่ ๆ ในอนาคต !!

เนื่องการทำ indexing ใหม่ หรือ reindexing ต้องใช้เวลาที่นาน นั่นหมายความว่าถ้าต้องการเพิ่ม feature ใหม่ ๆ เข้ามาในอนาคต ต้องทำมีค่าใช้จ่ายต่าง ๆ สูงมาก หรืออาจจะเป็นไปไม่ได้เลย (Exponential) เนื่องจากระบบปัจจุบันนั้นไม่สามารถทำสิ่งเหล่านี้ได้อย่างรวดเร็ว

เปลี่ยนแปลง sharing algorithm
เปลี่ยนแปลง Analyzer
เปลี่ยนแปลง Ranking
ติดปัญหาเรื่องข้อจำกัดของ JVM Heap size

จากทั้ง 3 เหตุผลนี้ทำให้ทางทีมพัฒนาคิดว่า

ต้องทำอะไรบางอย่างแล้ว ? ทั้งออกแบบและสร้างระบบใหม่ขึ้นมา ซึ่งมีเป้าหมายดังนี้

แยกการทำงานระหว่าง application layer และ backend service ออกจากกัน
เปลี่ยนแปลง code ได้รวดเร็วขึ้น
ง่ายต่อการ custom หรือแก้ไข ranking ต่าง ๆ
Realtime indexing
ว่าด้วยเรื่องของ performance ของระบบที่เพิ่มขึ้นต้องเป็น linear ตาม business และ feature ที่เพิ่มขึ้น

โดยทีมพัฒนามองว่า Elasticsearch คือหนึ่งในเครื่องมือที่น่าจะช่วยแก้ไขปัญหาต่าง ๆ เหล่านี้ได้ แต่เชื่อได้ว่า ต้องมีการ custom อะไรอีกมากมาย

ว่าง ๆ มารวบรวมคำสั่งและ shortcut ที่ใช้ประจำ ผ่าน terminal บน MacOs ของตัวเองไว้นิดหน่อย เขียนไว้กันลืม

คำสั่งที่ใช้บ่อยมาก ๆ ในแต่ละวัน

ประกอบไปด้วย

pwd แสดง working directory ในปัจจุบันซึ่งจะแสดง path เต็ม ๆ
ls แสดงรายชื่อไฟล์และ directory ต่าง ๆ
cd ทำการเปลี่ยนตำแหน่งไปยัง directory ที่ต้องการ ทั้งแบบ relative และ absolute path
mkdir สำหรับการสร้าง directory ใหม่ สร้างได้ทั้ง directory เดียวหรือหลาย ๆ directory พร้อม ๆ กัน
cp สำหรับการ copy ไฟล์และ directory
rm สำหรับการลบไฟล์
rm -r สำหรับลบ directory
touch สำหรับการสร้างไฟล์เปล่า ๆ ขึ้นมาใหม่
open . สำหรับการเปิด Finder

ส่วน shortcut ที่ใช้ใน terminal บ่อย ๆ

ประกอบไปด้วย

Control + A การย้าย cursor ไปต้นบรรทัด
Control + E การย้าย cursor ไปท้ายบรรทัด
Control + R สำหรับการค้นหาข้อมูลจาก history
Command + L ทำการ clear screen 1 บรรทัด
Command + K ทำการ clear screen ทั้งหน้า
Tab สำหรับ auto-suggestion

ใครมีคำสั่งและ shortcut ที่น่าสนใจ ก็มาบอกกันบ้างนะครับ ส่วน command และ shortcut ที่ผมใช้นั้นมันพื้นฐานสุด ๆ

ช่วงนี้มีโอกาสใช้งาน Array ของ Numpy library และ Series/DataFrame ของ Pandas library สำหรับการจัดการและวิเคราะห์ข้อมูลของระบบนิดหน่อย จากการใช้งานพบว่า ในการเข้าถึงข้อมูลของ Pandas นั้นช้ากว่า Numpy มากพอสมควร แต่ก็ยังเร็วกว่า Python standard library !! จึงลองทำ profiling ดูนิดหน่อย รวมทั้งการปรับปรุง code ให้ทำงานเร็วขึ้นบ้าง

เริ่มจากการวัดประสิทธิภาพในการเข้าถึงข้อมูล

โดยจะทำการสร้าง list ขนาด 1 ล้านขึ้นมาก่อน

สร้าง array ด้วย Numpy
สร้าง series ด้วย array จาก Numpy
ทำการสุ่ม index ขึ้นมา 100 ตัว เพื่อใช้ทดสอบเข้าถึงข้อมูล

[gist id="6d81f4bf7fc974cee7e86dbf9acc69f5" file="1.py"] จากนั้นทำการวัดประสิทธิภาพใน iPython ได้ผลดังนี้ [gist id="6d81f4bf7fc974cee7e86dbf9acc69f5" file="2.txt"] ผลที่ได้คือ การเข้าถึงข้อมูลในแต่ละ index ของ Numpy เร็วกว่า Pandas อย่างมาก นั่นคือการทำงานของ Numpy มีเวลาการทำงานอยู่ในหน่วย nanosecond ส่วนการทำงานของ Pandas มีเวลาการทำงานอยู่ในหน่วย milisecond !! ส่วนของ standard python อยู่ในหน่วย second !!!! ซึ่งต่างกันมากมายหลายร้อยเท่า ส่วนพวก operation ต่าง ๆ เช่น บวกลบคูณหารนั้นห่างกันไม่มากเท่าไร แต่ Numpy จะเร็วกว่า

คำถามที่เกิดขึ้นมาคือ แล้วใน Pandas มันไปทำอะไรนะ ถึงทำงานช้า ?

จะไปเปิด code อ่านดูก็น่าจะยากไปสำหรับการเริ่มต้น ดังนั้นจึงลองทำ profiling และนำ SnakeViz มาช่วยในการ visualization ของการทำงาน ด้วยคำสั่ง [code] In [15]: %snakeviz series[index] [/code] พบว่า การเข้าถึงข้อมูลใน Series ของ Pandas ทำงานเยอะมาก ๆ มีการเรียกมากกว่า 20 ชั้นสำหรับการดึงข้อมูล !! แสดงดังรูป

อาจจะดูแล้วยังงง ๆ ดังนั้นมาเปรียบเทียบกับการเข้าถึงข้อมูลใน array ของ Numpy แสดงผลดังนี้ ซึ่งไม่มีการเรียกหรือทำงานอะไรที่ซับซ้อนเลย จึงทำให้ผลการทำงานเร็วกว่ามาก ๆ

การปรับปรุง performance การทำงาน

เมื่อเราเห็นแล้วว่า Pandas มีการจัดการข้อมูลในรูปแบบ Series เยอะมาก ๆ ดังนั้นสิ่งที่เราต้องทำคือ แก้ไขปัญหา แทนที่จะทำการเข้าถึงข้อมูลผ่าน series ก็ทำการเปลี่ยนข้อมูลจาก series มาอยู่ในรูปแบบของ array ด้วย Numpy ก่อน ยกตัวอย่างเช่น [gist id="6d81f4bf7fc974cee7e86dbf9acc69f5" file="3.py"] โดยการทำงานของการเรียกใช้ property values นั้น มี performance ที่ดีมาก ๆ และได้ข้อมูลชนิด array numpy (numpy.ndarray) เมื่อได้ข้อมูลที่ต้องการก็นำไปใช้งานต่อไป

ขอให้สนุกกับการ coding ครับ

สำหรับภาษา Python นั้นเหมาะกับการทำ Data Analysis อย่างมาก เนื่องจากมี ecosystem และพวก library ต่าง ๆ ให้ใช้มากมาย แต่ในความมากมายนั้น กลับกลายเป็นภัยสำหรับผู้เริ่มต้น ดังนั้นจึงสรุป library หลัก ๆ สำหรับผู้เริ่มต้นไว้นิดหน่อย ค่อย ๆ ศึกษาและใช้งานกันไปนะ

เริ่มจากเรื่องพื้น ๆ ก่อนเลยคือ Python นั่นเอง

เป็นสิ่งที่ขาดไปไม่ได้เลย ทั้งเรื่องของการติดตั้ง Python ทั้งเรื่องการติดตั้ง library ต่าง ๆ รวมทั้งอาจจะนำเครื่องมือที่เป็นประโยชน์ต่าง ๆ มาใช้ เช่น Anaconda, iPython เป็นต้น ตลอดจนรูปแบบของภาษา Python เรื่องของ Data Structure ต่าง ๆ เรื่องของ List comprehension ดังนั้นพื้นฐานจึงสำคัญมาก ๆ จะทำให้เราสามารถศึกษาเรื่องอื่น ๆ ได้อย่างรวดเร็วมากขึ้น

จากนั้นจึงเริ่มนำ library พื้นฐานสำหรับ Data Analysis มาใช้

ประกอบไปด้วย

NumPy สำหรับการจัดการข้อมูลในรูปแบบ array หลายมิติ ซึ่งมีประสิทธิภาพที่สูงมาก ๆ และมี operation ต่าง ๆ เพื่ออำนวยความสะดวก
SciPy เป็นส่วนขยายต่อจาก NumPy สำหรับ operation ต่าง ๆ มากยิ่งขึ้น
Matplotlib เป็นส่วนการแสดงผลในรูปแบบ visualization
Jypyter เป็นเครื่องมือที่สร้างอยู่บน iPython แต่เป็น interative บน web browser ทำให้เราสามารถเขียน code, execute code และเอกสารต่าง ๆ อยู่ที่เดียวกัน เป็นเครื่องมือที่พลาดไม่ได้เลย

ต่อมาคือเรื่องของการจัดการและวิเคราะห์ข้อมูล

เป็นสิ่งที่จำเป็นอย่างมากในกระบวนการทำงาน เช่น

การ load ข้อมูล
การ cleaning ข้อมูล
การจัดการ missing value
การ tranform ข้อมูล
การวิเคราะห์ข้อมูล

ซึ่งมี library ที่ได้รับความนิยมมาก ๆ ประกอบไปด้วย

Pandas เป็น library ที่ได้รับความนิยมสุด ๆ สำหรับ Data Science เนื่องจากมี data structure ที่ดีและเครื่องมือในการวิเคราะห์ข้อมูลให้ครบ
xarray ได้รับแรงบันดาลในมาจาก Pandas นั่นเอง แต่สร้างมาเพื่อทำงานกับ array หลายมิติโดยเฉพาะ
scikit-learn เป็น library สำหรับ Machine Learning ที่ได้รับความนิยมสุด ๆ โดยมี algorithm ต่าง ๆ ทาง Machine Learning ให้ใช้งานอย่างครบครัน

เพียงเท่านี้ก็น่าจะทำให้ผู้เริ่มต้นอ้วกกันเป็นแถว ๆ แล้ว

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

Statsmodels ทำการเตรียม algorithm ต่าง ๆ ในเชิงสถิติไว้เพียบ และสามารถทำงานรวมกับ Pandas ได้เลย
seaborn สำหรับการ plot ข้อมูลในรูปแบบต่าง ๆ
Bokeh สำหรับการ plot ข้อมูลในรูปแบบ interactive ที่สวยงาม

แต่เหนือสิ่งอื่นใด พื้นฐานมันสำคัญมาก ๆ ขอให้สนุกกับการ coding ครับ

ปัญหาที่พบเจอ

ปกติในการใช้ Apache Maven จะทำการกำหนด local repository ที่ใช้เก็บ library ต่าง ๆ ซึ่งกำหนดทั้งในไฟล์ settings.xml และ ใน command line เช่น -Dmaven.repo.local ผลที่ออกมาคือ จะทำการ download จาก Remote repository อย่างเดียวเลย Software ที่ใช้งานประกอบไปด้วย

ระบบปฏิบัติการ Windows
Apache Maven 3.5.0

การแก้ไขปัญหา

เมื่อเข้าไปดูการทำงานของ Apache Maven พบว่า ในการ download library จาก Remote repository นั้น Apache Maven 3.x ขึ้นไปจะทำการสร้างไฟล์ต่าง ๆ เหล่านี้ใน ใน library ทุก ๆ ตัว

_remote.repositories
_maven.repositories

เพื่อบันทึกว่า library แต่ละตัวทำการ download มาจากที่ไหน !! จากปัญหาที่พบคือ มีไฟล์ _remote.repositories ขึ้นมา ดังนั้นทำให้ Apache Maven เข้าใจว่า ต้องทำการ download library มาจาก Remote repository เท่านั้น ดังนั้นแก้ไขง่าย ๆ ด้วยการลบไฟล์ _remote.repositories ให้หมด เพียงเท่านี้ปัญหาก็หายไปแล้ว

สำหรับชาว React และ React Native แล้วนั้น ผมคิดว่าน่าจะใช้ Storybook กันทุกคน !! ในการทำ snapshot testing ของ UI component แต่ละตัว ช่วยทำให้ชีวิตของนักพัฒนาง่ายและสะดวกสบายมากยิ่งขึ้น ยิ่งใน version 3.2 นี้ก็มีความสามารถที่น่าสนใจเพิ่มเข้ามา ประกอบไปด้วย

สนับสนุน Vue project แล้ว
สามารถสร้างกลุ่มย่อย ๆ ของ story ได้แล้ว ช่วยทำให้ระบบใหญ่ ๆ จัดการ story ได้ง่ายขึ้นมาก
สามารถ filter ชื่อ story ตามที่ต้องการได้
สำหรับ ReactNative app นั้น สามารถเปิด storybook ดูได้ผ่าน app บน device ได้แล้ว
เพิ่ม logo ของ storybook ใน terminal
ปรับปรุงเรื่องการจัดการ error ต่าง ๆ

อ่านเพิ่มเติมได้ที่ Storybook Release Note สิ่งที่น่าสนใจสำหรับ Storybook คือ เป็น library ที่ขับเคลื่อนด้วย communities จากทั้งโลก ซึ่งเห็นได้ชัดมาก ๆ ตั้งแต่ version 3.0 เป็นต้นมา สำหรับ developer คนไหนที่ยังไม่ใช้งาน Storybook ให้เริ่มเสียตั้งแต่วันนี้ครับ [code] $npm i -g @storybook/cli $cd my-vue-project $getstorybook $npm run storybook [/code] แล้วจะเจอแแบบนี้นะครับ

ขอให้สนุกกับการ coding ครับ Reference Websites https://medium.com/storybookjs/announcing-storybook-3-2-e00918a1764c

จากบทความเรื่อง Ten Things A Serious JavaScript Developer Should Learn ได้สรุป 10 เรื่องที่ JavaScript Developer ควรเรียนรู้ เพื่อช่วยให้เราเป็นนักพัฒนาที่ดีกว่าเดิม จึงได้ทำการสรุปและแปลในสิ่งที่น่าสนใจไว้นิดหน่อย น่าจะพอเป็นประโยชน์บ้างนะ

โดยเริ่มต้นมาจากคำถามใน Reddit “What 10 Things Should a Serious Javascript Developer Know Right Now?”

เรื่องที่ 1 พื้นฐานของภาษา JavaScript (Core language)

ด้วยตัวภาษา JavaScript นั้นไม่ได้ซับซ้อนอะไรมากนัก ทั้งขนาดและจำนวน standard library ต่าง ๆ แต่ว่าหลายสิ่งอย่างเกี่ยวกับ JavaScript มันทำให้มีความซับซ้อนมาก ทั้ง APIs ต่าง ๆ ทั้ง jQuery ทั้ง React ทั้ง TypeScript ทั้ง ES5/6/7 ทั้ง library ต่าง ๆ จาก NPM ดังนั้นสิ่งแรกที่ต้องศึกษาและเข้าใจคือ พื้นฐานของ JavaScript นี่เอง ประกอบไปด้วย

if/else
การจัดการ error handling ด้วย try/catch/throw
การจัดการ array ทั้ง push/map/reduce/filter
การจัดการ string ทั้ง replace/slice/split
การจัดการข้อมูลในรูปแบบ JSON

รวมไปถึงความสามารถใหม่ ๆ ที่เพิ่มเข้ามา เช่น async-await, Promise และ module เป็นต้น ช่วยทำให้เราเข้าใจสิ่งต่าง ๆ มากขึ้น ช่วยทำให้เรียนรู้สิ่งต่าง ๆ ได้รวดเร็วขึ้นอีกด้วย โดยหนังสือที่แนะนำให้อ่านคือ Eloquent Javascript และบทความเรื่อง How to follow the JavaScript roadmap ?

เรื่องที่ 2 เข้าใจเรื่อง Async code (Asynchonous)

เป็น code ที่เจอเป็นปกติของระบบที่พัฒนาด้วยภาษา JavaScript โดยผลการทำงานจะไม่ตอบกลับโดยทันที ซึ่งจะขัดแย้งกับภาษาอื่น ๆ พอสมควร สำหรับผู้เริ่มต้นอาจจะทำให้เกิดความเข้าใจผิดได้ สิ่งที่ควรเรียนรู้ประกอบไปด้วย

Callback
Promise
Event loop

จากนั้นลองเขียน code ด้วย standard library เช่น setTimeout และ fetch เป็นต้น รวมไปถึง feature ใหม่อย่างเช่น async-await และ RxJS

สิ่งที่สำคัญมาก ๆ คือ การลงมือใช้งานและเขียน async code ขึ้นมา เพื่อเรียนรู้และเข้าใจรูปแบบการทำงานอย่างแท้จริง

เรื่องที่ 3 ต้องใช้เครื่องมือในการพัฒนาให้คล่องแคล่ว

ความสามารถที่สำคัญของ JavaScript developer คือ สามารถ debug หรือค้นหาต้นเหตุของปัญหา รวมทั้งการทำความเข้าใจว่า code ของระบบทำงานอย่างไร โดยที่เครื่องมือต่าง ๆ สำหรับภาษา JavaScript นั้นมีมากมายให้เลือกใช้งาน ทั้ง browser เช่น Developer Tool ใน Google Chrome ทั้ง debugger ต่าง ๆ ใน IDE เช่น VSCode, WebStorm และ Atom เป็นต้น ดังนั้นนักพัฒนาจำเป็นต้องเชี่ยวชาญในเครื่องมือต่าง ๆ เหล่านี้ มิเช่นนั้นงานของคุณจะยากขึ้นอย่างมาก

เรื่องที่ 4 เรียนรู้งานการออกแบบขั้นพื้นฐาน

จะเรียนรู้เพียง JavaScript อย่างเดียวมันคงยังไม่พอ มันดูจะปิดกั้นเกินไปสักหน่อย ดังนั้นสิ่งที่ควรศึกษาเพิ่มเติมคือ HTML และ CSS จากนั้นทำการศึกษาเรื่องอื่น ๆ เพิ่มเติม เช่น

เรื่องที่ 5 เรียนรู้เกี่ยวกับการจัดการข้อมูลผ่านระบบ Network และ HTTP APIs

สิ่งที่นักพัฒนาต้องไม่พลาดหรือขาดไปคือ ความรู้พื้นฐานเกี่ยวกับระบบ Network ยิ่งความรู้เรื่อง HTTP protocol น่าจะขาดไม่ได้เลย ซึ่งสามารถนำมาต่อยอดในเรื่องของ REST APIs และ AJAX ได้อีกด้วย รวมไปถึงการเรียกใช้งาน APIs ต่าง ๆ ด้วย JavaScript อีกด้วย เรื่องเหล่านี้ไม่น่าจะต้องมาพูดคุยว่าทำอย่างไรอีกแล้ว น่าจะมาคุยว่าทำอย่างไรให้ดีมากกว่า

เรื่องที่ 6 ควรจะต้องรู้ว่าจะใช้ framework หรือ โครงสร้างระบบอย่างไร ในแต่ละงาน

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

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

ปล. อย่าลืมศึกษาเครื่องมือและ framework ต่าง ๆ ไว้ด้วย เพื่อทำให้เราเข้าใจว่าแต่ละอย่างถูกสร้างมาเพื่ออะไร และ เหมาะกับงานลักษณะไหน

เรื่องที่ 7 ต้องเรียนรู้สิ่งใหม่ ๆ อยู่อย่างสม่ำเสมอ

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

ปล. การเรียนรู้ไม่ใช่การนำมาใช้งานนะ !!

ยังมีเรื่องอื่น ๆ อีกนะครับ สามารถอ่านเพิ่มเติมได้ที่ Ten Things A Serious JavaScript Developer Should Learn

เมื่อวานเจอ code ที่น่าสนใจใน Slack ของ Kotlinlang แต่สิ่งที่สำคัญและน่าสนใจกว่าคือ ความสามารถใน code ของภาษา Kotlin นั่นเอง มันมีหลายสิ่งที่ควรค่าต่อการหยุดดูและศึกษา ดังนั้นมาลองดู code กันขำๆ กันหน่อย [gist id="b414a4f8430ad0d014c05ec74ef37f46" file="tip.kt"] ที่สำคัญ code ชุดนี้ทำงานได้ด้วยนะ ซึ่งสามารถทดสอบ run ด้วยคำสั่ง [code] $kotlinc tip.kt -include-runtime -d tip.jar $java -jar tip.jar [/code] ได้ผลคือ โยน exception ออกมาดังนี้ [code] Exception in thread "main" ┻━┻ at ┻━┻.<clinit>(tip.kt:1) at TipKt.main(tip.kt:11) [/code]

เริ่มจากชื่อ class และ object อันนี้ปกติ

แต่การตั้งชื่อแบบนี้ก็เล่นเอาฮาน้ำตาเล็ด แต่ในการทำงานจริง ๆ คงไม่มีใครอยากเจอหรอกนะ !!

ต่อมาคือเรื่องของ object declaration

จะเห็นว่ามีการใช้ keyword ชื่อว่า object เป็นการใช้งานตาม Singleton pattern นั่นเอง จะเรียกว่าเป็น static class ก็ว่าได้ ซึ่งมี instance เดียวเท่านั้น

อีก keyword คือ companion object

ทำการประกาศ object declaration ใน class ด้วย keyword ชื่อว่า companion โดยที่ class หลักสามารถเรียกใช้ method ใน object ได้โดยตรง

จาก code ตัวอย่างนั้นมีการใช้ infix notation ด้วย

ทำให้เราสามารถเรียกใช้งาน method แบบสวย ๆ ได้ แน่นอนว่าทำให้ code อ่านง่ายและเข้าใจได้ง่าย เนื่องจากมันอธิบายตัวมันเอง ที่สำคัญเป็น pure function ดังนั้นจึงไม่มี side effect ใด ๆ เลย ยกตัวอย่างเช่น [gist id="b414a4f8430ad0d014c05ec74ef37f46" file="my_infix.kt"]

อีกอย่างคือ Nothing

เป็น class ชนิดหนึ่งที่ไม่มี instance ในกรณีนี้ใส่เป็น return Type ของmethod/function หมายความว่า method/function ไม่มีทางที่จะ return อะไรออกมา ยกเว้นโยน exception ออกไปเท่านั้น

จะเห็นได้ว่า code ในภาษา Kotlin สั้น ๆ เพียงเท่านี้ กลับมารายละเอียดที่เยอะเอาเรื่องเหมือนกันนะ วันนี้เราศึกษาภาษา Kotlin กันหรือยัง ?

ขอให้สนุกกับการ coding ครับ

สำหรับการเริ่มต้นใช้งาน GraphQL นั้น พบว่าต้องใช้เครื่องมือและ library หลาย ๆ ตัว แน่นอนว่า ต้องลงมือทำเองทั้งหมด ทั้งการ configuration ต่าง ๆ ของ GraphQL ทั้งการดู schema ทั้งการตรวสอบ schema ซึ่งดูแล้วมันยากและกระจัดกระจายยังไงก็ไม่รู้ (แต่ถ้าเข้าใจก็ไม่ยากนะ) ดังนั้นมาหาเครื่องมือที่ช่วยทำให้การพัฒนาและใช้งานง่ายขึ้นหน่อย ก็ไปเจอมา 2 ตัวคือ

ตัวที่น่าสนใจคือ GraphQL CLI มาลองใช้งานดูกัน

เริ่มด้วยการติดตั้งผ่าน NPM

[code] $npm install -g graphql-cli [/code] ซึ่งมีความสามารถที่น่าสนใจดังนี้

ทำการสร้าง configuration ที่จำเป็นต่อการเริ่มต้น project
ทำการเพิ่ม endpoint
ทำการตรวจสอบ endpoint
ทำการดึงข้อมูล schema ของแต่ละ endpoint
ทำการเปรียบเทียบ schema ขอแต่ละ environment ได้ เช่น dev กับ prod เป็นต้น

อีกทั้งยังมีระบบ plugin ให้อีกด้วย เช่น

graphql-cli-voyager สำหรับแสดง schema ในรูปแบบ graph สวย ๆ
graphql-cli-faker สำหรับการ run fake server ด้วย schema ของเรา ทำงานผ่าน graphql-faker (แต่ยังไม่เสร็จนะ)

ตัวอย่างการแสดงข้อมูลของ Github API

ดังนั้นลองมาใช้งาน GraphQL CLI กันหน่อยสิ

ทำการ init configuration กันก่อน

[code] $graphql init [/code] สิ่งที่สำคัญคือ การกำหนด Endpoint URL ของ GraphQL การกำหนดชื่อ environment ของ Endpoint ผลการทำงานคือ จะดึง schema ของ GraphQL จาก endpoint ที่กำหนดไว้มายังไฟล์ schema.graphql

ทำการดึง schema ล่าสุดของ environment ต่าง ๆ ได้

เพื่อทำให้เราได้ schema ล่าสุดมาใช้งาน [code] $graphql get-schema <environment> [/code]

ทำการตรวจสอบ schema ได้ว่า

มี source หรือ endpoint มาจากที่ไหน ? ทำการแก้ไขล่าสุดเมื่อไร [code] $graphql schema-status [/code]

ทำการตรวจสอบว่า endpoint ยังเปิดให้ใช้งานหรือไม่ ?

[code] $graphql ping <environment> [/code]

ทำการตรวจสอบ schema ของแต่ละ environment ได้

เพื่อทำให้เรามั่นใจได้ว่า schema เหมือนกันจริง ๆ นะ [code] $graphql <first environment> <second environment> [/code]

ทำการดู schema ของ GraphQL APIs กันแบบ interactive ผ่าน web browser กัน

ทำให้เข้าใจ schema ได้ง่ายขึ้น ซึ่งเป็นการปรับปรุงและต่อยอดมาจาก GraphiQL นั่นเอง [code] $graphql graphql playground <environment> [/code] จะทำการเปิด browser ขึ้นมาตามนี้ มี document ของ schema ให้ดู มี auto-suggestion/completion ให้ ใช้งานง่ายมาก ๆ ถ้าเคยใช้งาน GraphiQL มานะ

ปิดท้ายด้วย GraphQL Faker กันหน่อย ซึ่งน่าจะมีประโยชน์มากพอควร

เป็นเครื่องมือช่วยในการจำลอง GraphQL server เพียงแค่กำหนด schema ต่าง ๆ ไว้และบันทึก จากนั้นเครื่องมือนี้จะสร้าง endpoint ให้เลย (เหมือนจริงแต่ข้อมูลจำลองเท่านั้น) รวมทั้งมี GraphiQL มาให้ใช้อีกด้วย ตัวอย่างของการกำหนด schema และข้อมูลจำลอง แสดงดังรูป

โดยรวมแล้วมันใช้งานง่ายมาก ๆ แถมทำให้ผู้ใช้งาน GraphQL สบายขึ้นอย่างมาก ดังนั้นมาลองใช้งานกันนะ

จากการ post เกี่ยวกับ source code ไปนิดหน่อย พบว่าใน comment มีแนะนำเกี่ยวกับ IOCCC หรือ The International Obfuscated C Code Contest เห็นชื่อแล้วตกใจน่าดูไม่คิดว่ามันจะมีอะไรแบบนี้ แต่น่าสนใจมาก ๆ จึงลองไปดู code ที่ชนะในแต่ละปีหน่อย เห็นแล้วต้องร้องโอ้ว แบบนี้ก็มีด้วย !! ดังนั้นมาดูกันนิดหน่อย

เป้าหมายของ IOCCC ชัดเจนมาก ๆ

To render obscure
To darken
To confuse

โดยให้เขียน code ด้วยภาษา C สามารถดู Guideline เพิ่มเติมได้นะ เข้าไปดูผลการแข่งขันพบว่ามีมาแล้ว 25 ครั้ง แต่สิ่งที่สนุกคือ code ของผู้ชนะนี่แหละ มาดูกันดีกว่า มันสุดติ่งมาก ๆ

มาดูกันหน่อยรูปสวยมาก ๆ !!

รูปนี้สวยและน่ารัก

มีความพยายามสูงมาก ๆ

เล็ก ๆ กระทัดรัด

Code บางชุดจะใช้ define กันไปถึงไหน

คำตอบคือ ทั้ง program นะ

ถามว่าวงเล็บเยอะไหม ? ตอบว่ามาก

ปิดด้วย QR Code ก็แล้วกัน

ขอเข้าห้องน้ำไปอ้วกก่อนครับ

สิ่งที่น่าสนใจสำหรับ Postman version 5 คือ ความสามารถสำหรับ Pro version หรือเสียเงินนั้น ได้เปิดให้ใช้งานได้แบบฟรีแล้ว ทั้ง

Mock server
Monitoring API
Publish document ของ API

มาลองดูการสร้าง Mock Server ด้วย Postman 5 กันหน่อย ซึ่งใช้งานง่ายมาก ๆ

ปล. แต่ต้องสมัครสมาชิกที่ Postman ก่อนนะ แล้วน่าจะทำให้การทดสอบ API เป็นเรื่องที่ง่ายและสนุกขึ้นอีกเยอะ

ขั้นแรกทำเปิดโปรแกรม Postman ขึ้นมาก่อน (จะบอกทำไม)

โดยผมใช้งาน app บน Google Chrome จากนั้นทำการสร้าง Request ต่าง ๆ ที่ต้องการ และบันทึกไว้ใน Collections ให้เรียบร้อย จากนั้นทำการ Run Collections จะเจอหน้าจอแบบนี้ ซึ่งมี Menu ย่อย ๆ ให้ทั้ง Document, Monitoring และ Mock ดังรูป

ขั้นตอนที่ 2 ทำการเพิ่ม Mock ให้กับ API ของเรา

โดยมีขั้นตอนดังนี้ เริ่มด้วยกดปุ่ม Add a mock จะแสดงหน้าจอดังนี้

ทำการกดปุ่ม Mock this collection โดย Postman จะสร้าง URL ของ Mock server มาให้ ซึ่งเราจะนำ URL นี้ไปใช้ต่อไป

จากนั้นทำการสร้าง Environment ใหม่ชื่อว่า Mock จะได้นำไปใช้งานง่าย ๆ ดังรูป

สิ่งที่ต้องทำเพิ่มเติมคือ การเรียก Mock server นั้นต้องการ X-Api-Key

ซึ่งต้องใส่เพิ่มไปใน HEADER ของ Request ทุก ๆ ตัว ดังนั้นไปหา key กันมาก่อน นั่นคือ ต้องไปสมัครสมาชิกก่อนนะ แล้วจะได้ Key ดังรูป

จากนั้นนำ API Key จาก Postman มาใส่ใน Header ของทุก ๆ Request โดยใช้ชื่อว่า X-Api-Key แต่แนวทางที่ดีกว่าคือ สร้าง Global variable ชื่อว่า postman_api_key ไว้ เพื่อจะได้ใช้งานได้จากทุก ๆ Request

จากนั้นก็มาสร้าง Header ใน Request ซะ

เพื่อความสะดวกขึ้นไปอีกก็ให้ทำการสร้าง Preset ไว้เลย การสร้าง Preset

การใช้งาน Preset

ขั้นตอนที่ 3 เมื่อทุกอย่างพร้อมก็ลอง Run กับ Mock environment หน่อยสิ

ผลคือเกิด error สิครับ Error ไม่มี Example หรือข้อมูลตัวอย่าง นั่นคือข้อมูล response นั่นเอง แสดงดังรูป

ดังนั้นทำการ Add Example เข้าไปในแต่ละ Request แต่จะเอา Example มาจากไหน ? ตอบง่าย ๆ เลยคือ ก็ทำการเอามาจาก API จริง ๆ ไง !! ดังนั้นให้เปลี่ยน environmemt ไปยัง API จริง จากนั้นก็เพิ่ม response เหล่านั้นไปยัง Example ต่อไปดังนี้

จากนั้นทำการ Run Request และเปลี่ยนไปใช้ Mock environment ได้ดังนี้ ไม่เกิด error แล้วนะ

ที่สำคัญในแต่ละ Request/API สามารถเพิ่ม Example ได้หลาย ๆ กรณีทั้ง success และ failure ได้เลย โดยสามารถอ่านเอกสารเพิ่มเติมได้ที่ Setup Mock เพียงเท่านี้เราก็สามารถสร้าง Mock API Server แบบง่าย ๆ ด้วย Postman ได้แล้ว ขอให้สนุกกับการทดสอบ API นะครับ