Quantcast
Channel: cc :: somkiat
Viewing all 1997 articles
Browse latest View live
↧

[แปล] C.A.R.E คือคุณสมบัติของนักพัฒนา software ที่ดี

March 1, 2017, 10:29 pm
$
0
0

จากบทความเรื่อง Software Engineer Traits ทำการสรุปคุณสมบัติที่จำเป็นสำหรับนักพัฒนา software ที่ดี ต้องประกอบไปด้วย 4 อย่างดังนี้
Curiosity Awareness Resoluteness Empathy
จึงทำการแปลและสรุปไว้นิดหน่อย มาเริ่มกันเลย

1. Curiosity

ต้องมีความกระตือรือร้นในการเรียนรู้อยู่อย่างเสมอ โดยไม่ต้องให้ใครมาบังคับ ทั้งสิ่งที่รู้และไม่รู้ เป็นสิ่งที่สำคัญอย่างมากต่อนักพัฒนา software (หรือใคร ๆ ก็ตาม) เช่น การเรียนรู้ภาษาโปรแกรมใหม่ ๆ โดยไม่ต้องให้ใครมาบังคับ การทดลองสร้างระบบใหม่ ๆ การทดลองทำในแนวทางใหม่ ๆ การแก้ไขปัญหาในแนวทางใหม่ ๆ การตั้งคำถามต่าง ๆ เพื่อค้นหาคำตอบ เพียงข้อแรก ลองคิดดูก่อนว่าเราเป็นอย่างไร ?

2. Awareness

แปลตรง ๆ คือ ความตระหนักหรือรับรู้ในสิ่งต่าง ๆในขณะนั้น ต้องเข้าใจว่าเหตุผลในการเลือกสิ่งต่าง ๆ คืออะไร สามารถอธิบายให้คนอื่น ๆ รู้และเข้าใจได้ ไม่ใช่เพียงแต่บอกว่า ทำตาม ๆ กันมา !! เช่น Architecture ของระบบ ทำไมต้องเป็นแบบนั้น หรือเป็นแบบนี้ไม่ได้หรือ ? ทำไมต้องเขียน code ชุดนี้ ? แบบนี้ ?
สิ่งที่ติดสินใจต้องลงมือทำด้วยนะ จึงจะเกิดผล
สุดท้ายสิ่งที่คิด ตัดสินใจ และลงมือทำเหล่านั้น จะเห็นเป็น pattern นั่นแหละคือ สิ่งที่เรียกว่า standard หรือ มาตรฐานต่อไป

3. Resoluteness

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

4. Empathy

แปลตรง ๆ เลยก็คือ เอาใจเขามาใส่ใจเรา มันสำคัญมาก ๆ สำหรับการทำงานเป็นทีม (TEAM) ซึ่งจะขัดแย้งมาก ๆ สำหรับบริษัทที่ต่างคนต่างทำงานของตัวเอง ลองกลับมามองในแง่ของนักพัฒนากันบ้าง เราเขียน code เพื่อคนอื่นไหม ? code อ่านง่ายไหม ? code เข้าใจง่ายไหม ? code แก้ไขง่ายไหม ? ดังนั้นต้องเขียน code ให้ออกมาดีนะ
ทั้ง 4 ข้อรวมกันอ่านว่า CARE น่าจะมีประโยชน์ต่อนักพัฒนา software บ้างนะครับ
↧
Search

DevOps :: Three ways principle จากหนังสือ The Phoenix Project

March 3, 2017, 2:29 am
$
0
0

จากหนังสือ The Phoenix Project มีเนื้อหาที่สนใจเกี่ยวกับ DevOps มากมาย หนึ่งในนั้นคือ Three ways ซึ่งเป็น principle สำคัญสำหรับ การทำความเข้าใจเกี่ยวกับ DevOps การวางแผนเกี่ยวกับ DevOps การนำเอาแนวคิด DevOps มาประยุกต์ใช้งาน ประกอบไปด้วย
  1. Flow principle
  2. Feedback principle
  3. Continual learning principle
มีรายละเอียดดังนี้

1. Flow principle

ให้ความสนใจไปที่ flow การทำงานในส่วนของ IT ว่าตั้งแต่เริ่มพัฒนาจนไปถึงส่งมอบและดูแลจัดการ เพื่อส่งมอบงานจาก business ไปยัง customer มีเป้าหมายเพื่อ optimize flow การทำงานให้สะดวก และ รวดเร็ว นั่นคือตั้งแต่ Development team ไปยัง Operation team แสดงดังรูป โดยในส่วนนี้จะนำแนวคิดของ Continuous Delivery และ Deployment pipeline มาใช้ ถ้านำไปเทียบกับ Lean ก็คือการทำความเข้าใจกับ Value Stream เพื่อดูว่ามี processการทำงานอะไร อย่างไร อะไรที่เป็นปัญหาหรืออุปสรรค รวมทั้งสิ่งใดสามารถให้ทำการแบบอัตโนมัติได้ เพื่อเพิ่มความเร็วของการทำงาน และลดงานต่าง ๆ ลงไป เพื่อไปทำอย่างอื่นที่สำคัญ มันคือการเพิ่ม productivity นั่นเอง

2. Feedback principle

เป็นสิ่งที่ต่อเนื่องมาจากข้อที่ 1 คือ Flow principle เพิ่มเติมเข้ามาคือเรื่องของ Feedback เป็น feedback ที่ได้รับกลับมาจากผู้ใช้งานจริง ๆ เป็น feedback ที่ได้รับกลับมาจากลูกค้าจริง ๆ เป็น feedback ที่ได้รับกลับมาจากทุกคนที่เกี่ยวข้อง
เป้าหมายเพื่อทำให้ทุกคนเห็นว่า แต่ละคนทำอะไร สิ่งที่แต่ละคนทำไปนั้นส่งผลกระทบอะไรบ้าง สิ่งที่ทำไปนั้นมีคุณภาพอย่างไร
เมื่อได้รับ feedback ต่าง ๆ มาแล้ว จากนั้นต้องทำการปรับปรุง flow การทำงาน เพื่อให้ได้ feedback กลับมารวดเร็วที่สุด ยิ่งถ้าสามารถได้รับบ feedback แบบอัตโนมัติได้ยิ่งดี แสดงดังรูป

3. Continual Learning Principle

เมื่อข้อที่ 1 และ 2 เกิดขึ้นมาอย่างดีแล้ว ก็จะเริ่มนำเอาแนวคิดเรื่องของ Continuous Learning และ Continuous Improvement เข้ามาประยุกต์ใช้ โดยมักจะมีคำถามต่าง ๆ เกิดขึ้นมาเช่น เราเรียนรู้อะไรจากสิ่งมอบ ? เราเรียนรู้อะไรจาก feedback ต่าง ๆ ? เราจะใช้ความรู้ที่ได้รับมาปรับปรุงการทำงานของ IT กันอย่างไร ? การเรียนรู้นั้นมันคือรากฐานของทุกสิ่งทุกอย่าง รวมถึงการลองทำในสิ่งต่าง ๆ ในแนวทางใหม่ ๆ เพื่อหาทางที่ดีกว่า เพื่อส่งมอบคุณค่าให้กับลูกค้าต่อไป เพื่อหาทางที่ดีกว่า สำหรับองค์กร ดังนั้นสิ่งที่จำเป็นมาก ๆ คือ feedback loop ที่รวดเร็ว ตัวอย่างเช่นการนำแนวคิดของ Hypothesis Driven Development มาใช้ หรือการตั้งสมมุติฐานในเรื่องต่าง ๆ เช่น สิ่งที่ทำน่าจะเป็นสิ่งที่ลูกค้าต้องการ จากนั้นทำการพัฒนาและส่งมอบ เพื่อให้ลูกค้าใช้งาน จากนั้นดูผลจาก feedback เพื่อเรียนรู้และปรับปรุงต่อไป ถ้าผลออกมาไม่ดี ก็ตัดทิ้งไปก็เท่านั้นเอง
การเรียนรู้จากข้อผิดพลาดเป็นสิ่งที่ดีมาก ๆ ถ้าเราสามารถรู้ข้อผิดพลาดนั้นได้อย่างรวดเร็ว
Feedback loop จะเร็วได้ก็ต้องมี flow ที่ดี Flow ที่ดีและ Feedback loop ที่เร็ว ก็มาจากการปรับปรุงอย่างต่อเนื่อง แสดงดังรูป
โดยที่ DevOps คือผลลัพธ์ที่ออกมาจากสิ่งต่าง ๆ จากข้างต้นนั่นเอง
↧
↧

[Kotlin] มาใช้งาน AsyncAwait สำหรับ Android app กัน

March 3, 2017, 9:37 pm
$
0
0

หลังจากที่ Kotlin 1.1.0 ปล่อยออกมา มี feature ที่น่าสนใจมาก ๆ คือ coroutine โดย coroutine นั้นพัฒนาบน Rx, CompletableFuture, NIO, JavaFX และ Swing แน่นอนว่าสามารถใช้งานบน Android และ JavaScript ได้ และ coroutine ได้นำแนวคิดมาจากภาษาอื่น ๆ ด้วย เช่น Generator/yield จากภาษา Python Channel/select จากภาษา Go Async/Await จากภาษา C# ดังนั้นลองนำมาใช้งานกันหน่อย ซึ่งใช้กับการพัฒนา Android app กันไปเลย

ในการพัฒนา Android app นั้นสิ่งที่ขาดไปไม่ได้เลยก็คือ

การจัดการข้อมูลผ่านระบบ Network รวมทั้งงานต่าง ๆ ผ่านระบบ I/O เช่นการดึงข้อมูลจาก REST API เช่นการดึงรูปภาพมาแสดงผล ซึ่งสิ่งที่นักพัฒนาทุกคนต้องจัดการให้ได้คือเรื่องของ Thread การทำงานเหล่านี้ต้องไม่ไปขัดขวางการทำงานของ UI Thread หรือไป block การทำงานของ UI นั่นเอง มิเช่นนั้น app จะ crash ได้ ( App XXX หยุดแล้ว ) หรือแม้แต่การทำงานใน Background thread ก็อย่าไปยุ่งกับการทำงานของ UI เช่นกัน มิเช่นนั้นก็จะมีปัญหาเช่นเดียวกัน โดยวิธีการจัดการก็มีหลากหลายมาก ๆ เพื่อทำให้การพัฒนา app ง่ายและสะดวกมากยิ่งขึ้น ยกตัวอย่างเช่น
  • จัดการ Thread ด้วยตัวเอง มันสนุกมาก ๆ
  • ใช้งาน AsyncTask ของ Android
  • ใช้งานพวก Callback ตัวอย่างเช่นการใช้งาน Retrofit เป็นต้น
  • ใช้งานพวก Rx เช่น AndroidRx เป็นต้น
  • ใช้งาน AsyncAwait
มาดูตัวอย่างการใช้งานนิดหน่อย

1. จัดการด้วย Thread ของ Java

ซึ่งเป็นวิธีการจัดการแบบ manual นั่นเองผ่าน Java Thread นั่นเอง ทำให้เราสามารถจัดการการทำงานได้ตามที่ต้องการ แต่ต้องมีความรู้และเข้าใจเรื่อง Threading Model พอสมควร code ตัวอย่างเป็นดังนี้ [gist id="9fcfb977b10c9935647e297e49b9d291" file="solution1.kt"] ปล. ยังเห็นว่ามีคนใช้งานเยอะอยู่นะ เพราะว่า บางทีไป copy มาจาก StackOverflow นั่นเอง

2. จัดการด้วย AsyncTask ของ Android

เป็นวิธีการที่ช่วงแรก ๆ นักพัฒนา Android app ต้องใช้งานทุกคน แต่คำถามคือ ทำไมมันใช้งานยากจัง ? จะเขียนเยอะไปไหน ? ปัจจุบันมีใครบ้างที่ยังใช้อยู่นะ ? code ตัวอย่างเป็นดังนี้ [gist id="9fcfb977b10c9935647e297e49b9d291" file="solution2.kt"]

ส่วนของ Callback และ Rx ไม่ขอพูดถึงนะครับ

เพราะว่ามันง่ายนะ แต่ก็ต้องแลกมาด้วยความรู้พื้นฐานต่าง ๆ ที่ต้องเข้าใจ มิเช่นนั้น ถ้านำไปใช้แบบไม่เข้าใจ ก็อาจจะเกิด Callback hell หรือ Pyramid of doom ได้ สำหรับการนำวิธีการ Callback ไปใช้งานแบบผิด ๆ หรือในภาษา Swift ก็เช่น Completion block อาจจะทำให้เกิด Block hell ได้ ส่วนเรื่องของ Rx ผมอธิบายได้ที่ blog เรื่อง Asynchornous สำหรับ Android ไว้แล้ว

มาถึงตัวล่าสุดคือ Async/Await กันบ้าง

ซึ่งมีคนใจดีพัฒนาให้ใช้งานชื่อว่า AsyncAwait แน่นอนว่าพัฒนาอยู่บน coroutine ของ Kotlin 1.1 นั่นเอง การใช้งานก็ไม่ยากเท่าไร เริ่มต้นต้องเขียน code อยู่ใน async block จากนั้นจึงใช้ await block สำหรับส่วนทำงานอื่น ๆ เช่น long running process โดยสามารถมี await block ได้มากกว่าหนึ่ง block นะ code ตัวอย่างเป็นดังนี้ [gist id="9fcfb977b10c9935647e297e49b9d291" file="solution3.kt"] ทำให้ตอนนี้เรามีทางเลือกในการใช้งานมากขึ้นและสะดวกขึ้นนะครับ Source code ตัวอย่างอยู่ที่ Github::Up1::Kotlin Android AsyncAwait Reference Websites https://medium.com/@haarman.niek/async-await-in-android-f0202cf31088#.b95ck5fll
↧

สวัสดี Async/Await ใน NodeJS

March 4, 2017, 8:44 am
$
0
0

เมื่อวานทำการเขียน blog สำหรับลองใช้งาน Async/Await ด้วยภาษา Kotlin ก็ไปเห็นว่าใน NodeJS 7.6 ขึ้นไปนั้น สามารถใช้งาน Async/Await ได้เลย ไม่ต้องมาใส่ flag hamony ในการ run แล้ว เนื่องจาก Google V8 version 5.5 ได้ทำการเพิ่ม Async function เข้ามานั่นเอง
ตอนนี้ NodeJS version 7.7.1 แล้วนะ
ดังนั้นลองมาใช้ดูกันหน่อยสิ

เป้าหมายหลักของ Async function

เพื่อเรียกใช้ code ที่เขียนด้วย Promise ได้ง่าย โดยใน function สามารถใช้ await เพื่อรอการทำงานของ Promise ส่งผลทำให้เขียน flow การทำงานแบบ Asynchornous ให้ดูเหมือน Synchornous ทำให้ code อ่านง่ายยิ่งขึ้น ที่สำคัญตัดเรื่องของ callback function ไปได้เลย

มาดูตัวอย่างกันนิดหน่อย

เป็นการปรับจาก Promise มาเป็น Async/Await เป็นการดึงข้อมูลจาก REST API ของ Github เริ่มจาก Promise กันก่อน [gist id="76c462894bb9583ce82e8ee52a1a6764" file="promise.js"]

ถ้า process การทำงานยาว ๆ หรือซับซ้อน

การใช้งาน Promise ก็ทำให้มึนงงหรือเกิดปัญหาได้ ดังนั้นถ้าต้องการวิธีการที่ง่ายและเรียบง่ายกว่า หนึ่งในนั้นคือ Async/Await นั่นเอง สามารถเขียนได้ประมาณนี้ [gist id="76c462894bb9583ce82e8ee52a1a6764" file="async.js"]

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

คำถามคือ ต่อไปคืออะไร ?
Callback -> Promise -> Generators(coroutine) -> Async/await -> ?
สวัสดี ขอให้สนุกกับการเขียน code ครับ Source code ตัวอย่างอยู่ที่ Github::Up1::NodeJS Async/Await Reference Website https://www.reddit.com/r/programming/comments/5vi1j0/node_76_with_asyncawait_marking_a_huge_step/?st=izve0nqd&sh=057a8413
↧

สิ่งที่เปลี่ยนแปลงไปใน Fastlane

March 6, 2017, 7:34 am
$
0
0

ในปีนี้ยังไม่ได้ทำการ update ข่าวสารเกี่ยวกับ Fastlane เลย พอดีว่าง ๆ เลยมาสรุปสิ่งที่เปลี่ยนแปลงไว้นิดหน่อย ซึ่งทำการเปลี่ยนแปลงไปในทางที่ดีมาก ๆ ตั้งแต่ Fastlane 2.0 ที่ปล่อยมาตั้งแต่ปลายปี 2559 ประกอบไปด้วย 1. เอกสารการใช้งานที่ Fastlane Docs 2. เครื่องมือต่าง ๆ อยู่ใน gem ตัวเดียวชื่อว่า fastlane ทำให้การใช้งานง่ายขึ้น ไม่ต้องทำการติดตั้งและ update gem แต่ละตัวอีกต่อไปแล้ว สามารถใช้คำสั่งตามนี้ได้เลย [code] $fastlane <tool name> [/code] ทำให้ง่ายต่อการ update ด้วยคำสั่ง [code] $fastlane update_fastlane [/code] หรือใช้งานผ่าน bundler ด้วยคำสั่ง [code] $bundle update [/code] 3. ในปีที่แล้ว fastlane เปิดให้นักพัฒนาสามารถเพิ่ม action/plugin เข้าไปได้อีกด้วย ซึ่งช่วยทำให้นักพัฒนาสามารถขยายความสามารถของ fastlane ได้อีกมากมาย 4. ในปีที่ผ่านมาพบว่า Fastlane นั้นมีความเสถียรมากขึ้นมาก สุดท้ายตอนนี้ทาง Fastlane ได้ย้ายเข้าไปอยู่ Google แล้วนะ ตามทีม Fabric ไปร่วมกับทีม Firebase นั่นเอง มาดูต่อไปว่า จะมีเครื่องมืออะไรดี ๆ สำหรับฝั่ง Android ออกมาเพิ่มอีกบ้าง
ถ้าใครยังไม่ได้ใช้งาน แนะนำว่าให้ลองเถอะครับ
↧
↧

ทำการแก้ไข Status Bar ของ Emulator สำหรับการใช้งานกับ snapshot

March 7, 2017, 6:13 pm
$
0
0

หลังจากที่ใช้งาน Fastlane snapshot แล้ว เกิดคำถามว่า เราสามารถเปลี่ยน Status Bar ของ Emulator ได้หรือไม่ ? เช่น ไม่อยากเห็นคำว่า Carrier อยากเปลี่ยนเวลา แสดงดังรูป

เมื่อลองค้นหาพบว่า

วิธีการที่ง่ายที่สุดคือ เอามาแก้ไขในโปรแกรมแก้ไขรูป !! กับอีกหนึ่งวิธีการคือ มีคนใจดีทำ library ชื่อว่า SimulatorStatusMagic มาให้ โดยทำการแก้ไข status bar ในขณะ runtime ดังนั้นลองนำมาใช้งานกันดีกว่า

1. ติดตั้งผ่าน Cocoapods

[gist id="2e85328fa17c4b753ee0058fff683d63" file="Podfile"] จากนั้นก็ทำการติดตั้งด้วยคำสั่ง [code] $pod install [/code]

2. เริ่มเขียน code ในส่วนของ UITest กันดีกว่า

สิ่งที่ต้องการประกอบไปด้วย
  • แก้ไขคำว่า Carrier เป็น Somkiat
  • ไม่แสดง WIFI
  • เปลี่ยนเวลาเป็น 15:00
สามารถเขียน code ได้ดังนี้ [gist id="2e85328fa17c4b753ee0058fff683d63" file="SampleUITests.swift"] คำอธิบาย
  • ทำการกำหนดค่าต่าง ๆ ใน method setUp() ซึ่งจะถูกเรียกก่อนจะทำการทดสอบในแต่ละ test case
  • โดยใน method setUp() จะทำการแก้ไข Status bar ตามที่ต้องการ
  • ทำการแก้ไขค่าของ Status bar กลับคืนสู่สภาวะเดิม
จากนั้นทำการ run fastlane ด้วยคำสั่ง [code][/code] $fastlane snapshot /code] แสดงผลการทำงานดังรูป ตัวอย่างของ source code อยู่ที่ Github::Up1:Demo Fastlane Snapshot ขอให้สนุกกับการเขียน code ครับ Reference Websites https://medium.com/@juli1quere/a-perfect-status-bar-on-screenshots-with-fastlane-84a94a350b2a#.73x0p3unx
↧

มาเป็น programmer ได้อย่างไร ?

March 8, 2017, 7:18 am
$
0
0

ช่วงต้นปีใน facebook มีคำถามที่น่าสนใจมาก ๆ คือ มาเป็น programmer ได้อย่างไร ? ก็เลยนำมาตอบด้วยการเขียน blog สักหน่อย ว่าตัวผมเองมาเป็น programmer ได้อย่างไร ? มาเริ่มกันเลย

เริ่มจากสมัยมัธยมปลายเรียนที่โรงเรียนราชสีมาวิทยาลัย ที่โคราช

จำได้ลาง ๆ ว่าครั้งแรกที่ได้จับ computer คือ การเรียนวิชาหนึ่งที่เป็นการใช้ computer นี่แหละ ต้องเข้าห้อง lab เพื่อไปเรียนโปรแกรม paint มั้ง จากนั้นก็ไม่ได้จับอีกเลย การจับครั้งนี้ไม่ได้เปิดเครื่องหรือปิดเครื่องเองอีกด้วย เรื่องของ internet ไม่ต้องพูดถึง ไม่รู้จักแน่นอน ฟังเพลง online ไม่มีแน่นอน เพราะว่ายังซื้อเทปเป็นตลับฟังกันอยู่เลย อ่านหนังสือการ์ตูนกันอยู่เลย พวก C-KID, Boom อะไรทำนองนั้น กับแกะ sticker กับเพื่อน ๆ รวมทั้งเตะบอลพลาสติกกับเพื่อน ๆ ครั้งแรกที่รู้จัก internet คือ เพื่อน ๆ บอกว่าไปตรวจสอบผลการสอบโควต้า เพื่อเข้าเรียนต่อในระดับมหาวิทยาลัยเท่านั้นเอง
ดังนั้นสมัยมัธยมความรู้เรื่อง computer น่าจะเท่ากับศูนย์ ส่วนคำว่า programmer คืออะไรไม่รู้จัก !!
มาถึงตรงนี้ไม่น่าจะมาเป็น programmer ได้เลย ผมก็งงเช่นกันว่ามาเป็นได้อย่างไร !!

ช่วงที่สอง สอบติดโควต้า Computer Science ที่มหาวิทยาลัยอุบลราชธานี

คำถามที่น่าสนใจคือ ไม่รู้เรื่อง computer แล้วมาสอบเข้า Computer Science ทำไม ? คำตอบง่าย ๆ เลยคือ รุ่นพี่มาแนะแนวแล้วบอกว่า ที่นี่ไม่มีเรียนวิชาชีววิทยานะ !! เพียงเท่านี้ก็ทำให้โยนใบสมัครของที่อื่นในอีสานทิ้งไปหมดเลย ความหลังครั้งก่อนคือ เกรดวิชาชีวิทยาตอนมัธยมของผมคือ 0 นะ เป็นเกรด 0 แห่งความทรงจำ น่าจะตัวเดียวเลยก็ว่าได้ ดังนั้นมันจึงเป็นตัวเลือกหลัก ๆ ของการเลือกมหาวิทยาลัยเรียนต่อเลย โดยที่ไม่ได้คิดเลยว่า ต้องไปเรียน computer หรือไปเขียน code อะไร !! เพียงด้วยเหตุผลเท่านี้ก็เลือกลงกันเลย ที่สำคัญมีเพื่อน ๆ จากโรงเรียนเดียวกันไป 5 คนอีก ทำให้สบายใจขึ้นเยอะ เพราะว่ามีเพื่อนไปเรียนด้วยแล้ว ถ้าจำไม่ผิดจาก 5 คนจบอยู่ 3 คน !!
ผมคิดว่าตรงนี้แหละคือจุดเริ่มต้นแบบงง ๆ ที่สำคัญไม่รู้อนาคตอีกด้วยว่าจะเป็นอะไร ติด ๆ ไปก่อน เรียน ๆ ไปก่อนก็แล้วกัน

ช่วงที่สามครั้งแรกกับการเข้า Lab วิชา Programming 1

วิชาอื่น ๆ ที่เรียนผมคิดว่า ไม่ใช่ปัญหาเท่าไร เพราะว่าตั้งใจอ่าน ตั้งใจทำก็ได้แล้วมั้ง !! แต่มีวิชา Programming 1 นี่แหละที่มันคือจุดเปลี่ยนในชีวิต วันแรกของการเข้า Lab จำได้ขึ้นใจ อาจารย์บอกว่านักศึกษา Computer Science ไม่ให้ลงวิชา Computer เบื้องต้นนะ แต่ในครั้งแรกจะสอน computer เบื้องต้นให้ก่อน ต่อจากนั้นจะเขียน program ล้วน ๆ มาครั้งแรกให้เข้า cmd หรือ DOS mode นั่นเอง นั่งจับคู่กัน ช่วยกันทำ เป็นสิ่งที่จำไม่เคยลืมคือ ทำอะไรไม่ได้เลย งงไปหมด !!! ทั้ง ๆ ที่มันคือการ สร้างไฟล์ สร้าง folder ย้าย folder copy ไฟล์ เพียงเท่านี้ผมยังนั่งงง ทำไม่ได้เลย ยังไม่พอ เปิดและปิดเครื่อง computer ไม่เป็น มันเป็นวันแรกที่ลืมไม่ลงจริง ๆ วันแรกของการเขียน code จากนั้นสิ่งที่ต้องเรียนและเขียนคือ ภาษา C โดยใช้ Turbo C เป็นสิ่งที่สนุกมาก ๆ เพราะว่า เขียนไม่เป็น พิมพ์ช้าอีก ช้าไม่พอ ดันพิมพ์ดังอีก เพราะว่าติดจากการพิมพ์ด้วยพิมพ์ดีด ดังนั้นสิ่งที่บอกกับตัวเองคือ เอาไงดีหว่า ? มันต้องฝึกแล้วมั้ง ? ดังนั้นหลังจากนั้นพยายามเข้าห้อง Lab ฝึกตลอดเลย แต่ห้อง Lab มี computer ไม่เยอะอีก ดังนั้นต้องแย่งหรือเข้าคิวนะครับ ยังไม่พอช่วงแรก ๆ ยัง copy code เพื่อน ๆ ส่งกันอยู่เลย !! สมัยนั้นส่งด้วย floppy disk 3.5 1.44mb นะครับ พออาจารย์ส่งแผ่นกลับมา มันมักจะมาเป็นกอง แต่ละกองก็มาจากต้นฉบับเดียวกัน !! มาถึงตรงนี้ก็ยังไม่เห็นหนทางในการเป็น programmer เลย สิ่งที่คิดอย่างเดียวคือ ก็ต้องเรียน และ พยายาม นั่นแหละ พยายามจนจบปีแรกได้ ได้เกรดที่ไม่อยากจะเชื่อเลย ชีวิตนี้ไม่เคยได้เลย แต่ความสามารถทางด้าน computer และ programming ยังเรียกว่าต่ำแบบถูไถไปได้

ช่วงที่สี่ เริ่มหาทางของตัวเอง

พอผ่านช่วงปีแรกแห่งการเปลี่ยนแปลงมากมายมาได้ เริ่มปีสองด้วยการเรียนวิชาเฉพาะทางมากขึ้น ทำให้การเรียนเข้มข้นมากขึ้น เริ่มเข้าใจมากขึ้น แต่ก็ได้ใส่ใจและพยายามมากขึ้น รวมทั้งได้เรียนวิชา Data Structure and Algorithm ทำให้เข้าใจโลกของการคิดแบบเป้นขั้นตอนวิธีมากขึ้น ทำให้การเขียน program ดีขึ้นมา รวมทั้งเป็นครั้งแรกที่ได้เขียน program ภาษา Java อาจารย์ผู้สอนโหดร้ายมาก ๆ เพราะว่า ทำการ print code ภาษา Java มาให้ จากนั้นให้ทุก ๆ คนพิมพ์ตาม จากนั้นให้ขั้นตอนการ compile และ run มาให้ เพียงเท่านี้เอง ใช้เวลาเป็นสัปดาห์ในการทำ จากนั้นก็ต้องใช้ภาษานี้ตลอดมา โดยที่มหาวิทยาลัยไม่มีการสอน Java เลย (รุ่นผมไม่มีนะ แต่รุ่นน้องมี) จากนั้นก็ได้เขียน program ภาษาอื่น ๆ อีกแบบงู ๆ ปลา ๆ เช่น
  • Assembly
  • Perl
  • Pascal
  • Delphi
  • ASP
  • Visual Basic
จำได้ว่าทำ project จบด้วยภาษา Java และ J2EE (ปัจจุบันคือ JavaEE)
ปล. เหมือนคนแก่มานึกถึงความหลังกันเลย
นี่ก็น่าจะเป็นจุดเริ่มต้นของการก้ามมาสู่ Programmer ของผมเลย สิ่งที่ผมได้มามาก ๆ คือ ความรู้พื้นฐานต่าง ๆ ที่ช่วยให้เราพร้อมจะเรียนรู้สิ่งใหม่ ๆ อยู่อย่างเสมอ ส่วนความสามารถไม่ต้องพูดถึงเท่ากับ คนเริ่มทำงานใหม่ ๆ นั่นแหละ เรื่องหลังจากนี้ยาวมาก ๆ เพราะว่าต้องเรียนรู้ใหม่หมดเลย ตอนเรียนอ่านหนังสือมากเท่า พอมาทำงานอ่านมากกว่า 2 เท่าอย่างแน่นอน
ที่สำคัญอาจารย์ที่ปรึกษาบอกว่า ถ้าคุณอยากรู้ว่าสิ่งที่เรียนมาเอาไปใช้อย่างไร แนะนำให้คุณไปทำงานก่อน จากนั้นค่อยว่ากันว่าชอบหรือไม่ น่าจะเป็นคำแนะนำที่ทำให้ผมเข้าสู่การเป็น programmer นั่นเอง
↧

บันทึกการ migrate Elasticsearch 1.7 ไปยัง 5.X แบบผิว ๆ

March 10, 2017, 3:06 am
$
0
0

ทำการบันทึกการ migrate ข้อมูลในระบบงานจาก Elasticsearch 1.7 ไปยัง 5.x ซึ่งพบว่ามีสิ่งต่าง ๆ ที่เปลี่ยนไปเยอะพอสมควรประกอบไปด้วย
  • เรื่องการ mapping ของ index ที่เปลี่ยนไปเยอะพอสมควร
  • ใน Elasticsearch 5.x ไม่มีชนิดข้อมูลที่เป็น string แล้วนะ
  • Query DSL หลาย ๆ ตัวถูกตัดทิ้งไปแล้วเช่น filterred เป็นต้น
  • Aggregate API ที่เปลี่ยนไปเช่น size=0 ในการดึงข้อมูลถูกเอาออกไป เนื่องจากมีปัญหาเรื่อง performance
  • การ configuration Elasticsearch ก่อนที่จะ deploy
มีรายละเอียดดังนี้

1. ชนิดข้อมูล String ไม่มีแล้วนะ

จะมีชนิดข้อมูล text เข้ามาแทน ซึ่งเป็น full-text search รวมทั้งจะทำสร้าง multi-field ชื่อว่า keyword มีชนิด keyword ให้แบบอัตโนมัติ มีหน้าที่แทนการกำหนด index=not_analyze สามารถเรียกใช้งาน keyword ได้ด้วย field_name.keyword โดยเราสามารถแก้ไขชื่อของ keyword ได้ [gist id="f5beb6a2700658f868beed6722d9fc02" file="mapping.txt"]

2. เปลี่ยน Query DSL จาก filtered query มาเป็น boolean query

เนื่องจาก filtered query ถูกเอาออกไปแล้ว [gist id="f5beb6a2700658f868beed6722d9fc02" file="filtered.txt"] สามารถแก้ไขได้ดังตัวอย่าง [gist id="f5beb6a2700658f868beed6722d9fc02" file="boolean.txt"]

3. ใน Aggregate API นั้นพบว่า size=0 นั้นถูกลบออกไป

เนื่องจากมีปัญหา Issue 18838 คือเรื่อง performance การทำงานนั่นเอง ใช้สำหรับกำหนดจำนวนข้อมูลในแต่ละ bucket ดังนั้นสิ่งที่ต้องทำก็คือ กำหนด size ไปเองที่มากกว่า 0 เท่านั้นเอง รวมทั้ง field ที่จะ aggregate ต้องกำหนดเป็น fielddata ด้วยนะ หรือเป็น field ที่เป็นตัวเลข หรือ keyword นั่นเอง ตัวอย่างเช่น [gist id="f5beb6a2700658f868beed6722d9fc02" file="aggs.txt"]

4. ในการ configuration ของ Elasticsearch server ก็เปลี่ยนเยอะพอสมควร

ใน Elasticsearch 5.2.2 นั้น จะแยกออกเป็นสอง mode คือ development และ production โดยค่า default จะเป็น development mode คือทำงานได้เฉพาะเครื่องหรือ localhost เท่านั้น ดังนั้นถ้าจะทำการ deploy ไปยัง production ตัวอย่างเช่น [code] network.host: ip discovery.zen.ping.unicast.hosts: ["host1", "host2"] [/code] ส่วนค่า default ของ ES HEAP คือ 2 GB นะครับ ซึ่งแนะนำให้เปลี่ยนนะครับสัก 4-8 GB เป็นค่าเริ่มต้น ที่สำคัญใน Elasticsearch ยังแนะนำ checklist ต่าง ๆ ในการ configuration สุดท้ายอย่าลืมทดสอบให้มากนะครับ
↧
Search

เริ่มต้นศึกษา TypeScript ด้วยแนวทาง Test-Driven Development (TDD)

March 11, 2017, 4:12 am
$
0
0

ในการศึกษาภาษาใหม่ ๆ ด้วยแนวทาง Test-Driven Development (TDD) เป็นสิ่งที่ผมเชื่อว่าเป็นแนวทางที่ทำให้เข้าใจภาษาต่าง ๆ ได้รวดเร็วขึ้น ดังนั้นมาลองศึกษาภาษา TypeScript กันหน่อย ซึ่งถูกสร้างขึ้นมาจากบริษัท Microsoft และเป็น opensource ในการใช้งานจะต้อง compile มาเป็นภาษา JavaScript ก่อนเสมอ ดูแล้วขั้นตอนเยอะเลยนะ ดังนั้นมาเริ่มต้นศึกษาด้วย Hello World กันหน่อย

1. สำหรับผู้เริ่มต้นศึกษา TypeScript

แนะนำให้ลองไปฝึกเขียนผ่าน TypeScript Playground ก่อนเลย เพื่อใช้ฝึกเขียนและศึกษา syntax ของตัวภาษา ทำให้เราเห็นว่า code ที่เขียนนั้นจะถูกแปลงไปเป็น JavaScript และสามารถ run ได้อีกด้วย แสดงดังรูป

2. หลังจากนั้นมาสร้าง Application หรือ Project กันหน่อย

โดยเราจะทำแบบ step-by-step กันเลยดังนี้ 2.1 สร้าง application ชื่อว่า helloworld ด้วยคำสั่ง [code] $mkdir helloworld $cd helloworld $npm init [/code] 2.2 เพื่อความง่ายกำหนด dependency ที่เราต้องการในไฟล์ package.json โดย dependency ที่นำมาใช้งานประกอบไปด้วย [gist id="ae097e63c9cc09aed89b64333b2e98b6" file="package.json"] จากนั้นทำการติดตั้ง dependency ต่าง ๆ ด้วยคำสั่ง [code] $npm install [/code] 2.3 ทำการสร้าง folder สำหรับเก็บ code ต่าง ๆ ประกอบไปด้วย
  • จัดเก็บ production code ใน folder src
  • จัดเก็บ test code ใน folder tests
  • จัดเก็บ output หรือผลการทำงานต่าง ๆ ใน folder dist
ด้วยคำสั่ง [code] $mkdir src $mkdir tests $mkdir dist [/code] 2.4 ทำการ configuration สำหรับ TypeScript ว่าจะให้ทำการ compile ด้วยมาตรฐานอะไรเช่น ES5, ES6 เป็นต้น และผลการ compile จะเก็บไว้ที่ไหน และ folder อะไรบ้างที่ไม่สนใจ โดยกำหนดไว้ในไฟล์ tsconfig.json ดังนี้ [gist id="ae097e63c9cc09aed89b64333b2e98b6" file="tsconfig.json"] 2.5 เขียน test code และ production code ด้วย TypeScript สิ่งที่ต้องการคือ สร้าง function sayHi รับข้อมูลคือ ชื่อ จากนั้นทำการส่งคำว่า Hi, ชื่อ กลับคืนมา สามารถเขียนได้ดังนี้ test code จะเก็บไว้ใน folder tests [gist id="ae097e63c9cc09aed89b64333b2e98b6" file="HelloWorldTest.ts"] production code จะเก็บไว้ใน folder src [gist id="ae097e63c9cc09aed89b64333b2e98b6" file="HelloWorld.ts"] 2.6 จากนั้นทำการทดสอบ เพื่อความง่ายทำการกำหนด script สำหรับ run ไว้ในไฟล์ package.json ดังนี้ [gist id="ae097e63c9cc09aed89b64333b2e98b6" file="package2.json"] ทำการทดสอบด้วยคำสั่ง [code] $npm test [/code] ผลการทดสอบเป็นดังรูป เพียงเท่านี้เราก็สามารถเริ่มต้นศึกษาภาษา TypeScript ตามแนวคิด TDD ได้แล้วนะครับ ตัวอย่าง source code อยู่ที่ Github::Up1::TDD with TypeScript
↧
↧

ถ้า Team เป็นแบบนี้น่าจะดีไม่น้อยนะ …

March 12, 2017, 8:32 pm
$
0
0

ถ้าในทีมพัฒนามีคนที่มีความสามารถในด้านต่าง ๆ ซึ่งเหมาะสมสำหรับการพัฒนาและส่งมอบระบบงาน น่าจะดีนะ ถ้าทีมเป็นแบบนั้นน่าจะดีนะ ถ้าทีมเป็นแบบนี้น่าจะดีนะ แล้วแบบไหนน่าจะดี ? น่าคิดนะ

ถ้าในทุก ๆ รอบการทำงานจบด้วยสิ่งที่ Release ได้เลย

มันน่าจะดีไม่น้อยนะ นั่นหมายความว่าทีมรู้และเข้าใจว่า ในแต่ละรอบการทำงานต้องทำอะไรบ้าง และที่สำคัญมันต้องเสร็จ เสร็จ เสร็จจริง ๆ ดังนั้นคำว่า Releasable จึงสำคัญมาก ๆ มันทำให้เราเห็นปัญหาได้อย่างรวดเร็ว แน่นอนว่าต้องปรับและแก้ไขให้สามารถ release ได้ นั่นหมายความว่าต้องถึงมือผู้ใช้งานและลูกค้า ลองคิดดูสิว่า ถ้าสิ่งที่บอกว่าเสร็จมันยังไม่ release เช่น integration server, internal server เป็นต้น สิ่งเหล่านั้นมันคือสิ่งที่ยังไม่เสร็จ สุดท้ายก็ต้องมานั่ง rework กันอีกรอบหรือหลาย ๆ รอบ

ถ้าการจัดเรียงความสำคัญของงานไม่ได้ทำเพียงคนเดียว แต่มีทีมพัฒนาเข้าไปด้วย

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

ถ้าในทุก ๆ วัน ทุก ๆ เวลามีการแสดงและบอกว่า มีอะไรบ้างที่เสร็จ

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

ถ้าทุกคนในทีมช่วยกันแก้ไขปัญหา

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

ถ้าการประชุมต่าง ๆ เช่นการวางแผนงานในแต่ละรอบมันสั้น ๆ

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

สุดท้ายแล้วทีมมีความสุขกับสิ่งที่ทำหรือไม่

มันดูได้จากอะไร ? ถ้าไม่ใช่จากคนในทีม และสิ่งที่ทีมสร้างมันออกมา ปล. ถ้ามีแต่บอกว่า ยังก่อน เรายังไม่พร้อม งานเราเยอะ .. ถ้าอย่างนั้น เราก็ไม่ปรับปรุงหรือพัฒนาอะไรเลย สุดท้ายก็จะมีข้ออ้างเสมอ ถ้า ... แต่ ...
ดังนั้นให้ค่อย ๆ ปรับปรุงทีละเล็กทีละน้อยแต่ประจำครับ
  Reference Website https://www.frontrowagile.com/blog/posts/98-5-signs-your-team-is-on-the-path-to-agility https://www.frontrowagile.com/blog/posts/92-mixing-roles-in-a-scrum-team https://www.frontrowagile.com/blog/posts/78-5-signs-your-team-is-lacking-the-agile-mindset
↧

เพื่อความสนุกมาเขียน Unit testingในภาษา R กัน

March 13, 2017, 3:49 am
$
0
0

หลังจากที่เขียนภาษา R มาสักพัก สิ่งที่น่าสนใจ และ ตั้งคำถามไว้คือ ถ้าอยากเขียน Unit test ในภาษา R มันมี xUnit framework อะไรให้ใช้หรือไม่ ? เมื่อไปค้นหาก็เจอเยอะเลย เช่น
  • RUnit ทำการ update ล่าสุดในปี 2015
  • svUnit ทำการ update ล่าสุดในปี 2014
  • testthat ทำการ update ล่าสุดในปี 2016
ดูจากการ update แล้วมาลองใช้งาน testthat กันหน่อยดีกว่า

เริ่มด้วยการ configuration และโครงสร้าง project ก่อนเลย

  • เก็บ production code ไว้ใน folder src
  • เก็บ test code ไว้ใน folder tests
จากนั้นทำการสร้างไฟล์หลักสำหรับการทดสอบ ชื่อว่าไฟล์ run-test.R เพื่อบอกว่าใช้ library ชื่อว่า testthat สำหรับการทดสอบ เพื่อบอกว่าจะทดสอบไฟล์อะไรบ้าง เพื่อบอกว่าชุดการทดสอบอยู่ที่ไหน ดังนี้ [gist id="0f88d05e1d4799dd8db2d263d5d15bf8" file="run-test.R"] ทำการทดสอบด้วยคำสั่ง [code] $Rscript run-test.R [/code] แน่นอนว่าต้องเจอ error โดย error แรกก็คือไม่เจอไฟล์ fizzbuzz.R ใน folder src ดังนั้นทำการสร้างไฟล์ก่อน [gist id="0f88d05e1d4799dd8db2d263d5d15bf8" file="error01.txt"] จากนั้นทำการ run ด้วยคำสั่งเดิมจะเจอ error ต่อมา คือ ไม่พบไฟล์ test ใน folder tests เลย [gist id="0f88d05e1d4799dd8db2d263d5d15bf8" file="error02.txt"] ซึ่งรูปแบบของชื่อไฟล์เป็นไปตาม regular expression ดังนี้ "^test.*\\.[rR]$" นั่นคือชื่อไฟล์ขึ้นต้นด้วย test. และมีนามสกุล r หรือ R ก็ได้ ยกตัวอย่างเช่น test.fizzbuzz.R หลังจากสร้างไฟล์ทุกอย่างเรียบร้อยทำการ run คำสั่งเดิม จะแสดงผลดังนี้ ถือว่าพร้อมสำหรับการเขียน unit test แล้ว [code] DONE ================= [/code]

เมื่อทุกอย่างพร้อมก็เริ่มเขียน test กันเถอะครับ

ซึ่งเขียนตามรูปแบบของ testthat ดังนี้ [gist id="0f88d05e1d4799dd8db2d263d5d15bf8" file="test.fizzbuzz.R"] คำอธิบาย
  • context ใช้อธิบายกลุ่มการทดสอบ
  • test_that ทำการกำหนดชื่อการทดสอบ โครงสร้างคล้าย jasmine มาก ๆ
จากนั้นทำการ run การทดสอบได้ผลดังนี้ [gist id="0f88d05e1d4799dd8db2d263d5d15bf8" file="test-error.txt"] จะเห็นได้ว่า error message แจ้งข้อผิดพลาดต่าง ๆ มาหมดเลย เช่นชื่อ function say() นั้นหาไม่เจอนะ

เมื่อ test fail แล้วก็ได้เวลาเขียน production code นะสิ

ก็เขียน code ง่าย ๆ เพื่อทำให้ชุดการทดสอบผ่านดังนี้ [gist id="0f88d05e1d4799dd8db2d263d5d15bf8" file="fizzbuzz.R"] ผลการทำงานผ่านสิ [code] TDD with R language: . DONE ================== [/code] สังเกตุไหมว่ามีจุด (.) จำนวน 1 จุดนะ นั่นคือจำนวนของชุดการทดสอบนั่นเอง
เพียงเท่านี้ก็สามารถเริ่มเขียน Unit testing สำหรับภาษา R ได้แล้วครับ
ปล. ทำไปเพื่ออะไร ? ตอบง่าย ๆ คือ อยากทำเท่านั้นเองนะ Source code ตัวอย่างอยู่ที่ Github::Up1::TDD with R
↧

เมื่อ Google ปล่อย API Design Guide ออกมา

March 14, 2017, 8:25 am
$
0
0

ต้นเดือนมีนาคมที่ผ่านทาง Google ได้ปล่อย API Design Guide ออกมา ซึ่งเป็นแนวทางสำหรับการออกแบบ API ต่าง ๆ ของ Google ไม่ว่าจะเป็น Cloud API และ Google API อื่น ๆ มาตั้งแต่ปี 2014 โดยเป้าหมายของเอกสารชุดนี้เพื่อ ช่วยทำให้การทำงานร่วมกันได้ดียิ่งขึ้นประกอบไปด้วย
  • Simple
  • Consistent
  • Easy-to-use

ในเอกสารนี้จะอธิบายการนำแนวคิดของ REST

มาประยุกต์ใช้กับออกแบบ API ในภาษาโปรแกรมต่าง ๆ ในระบบปฏิบัติการต่าง ๆ ใน protocol ต่าง ๆ

สุดท้ายเพื่อความสนุกในการออกแบบ API

แนะนำให้ลองใช้ API Stylebook จะมี API Design Guideline ต่าง ๆ ที่น่าสนใจ อีกทั้งยังสามารถสร้างและแบ่งปันให้คนอื่น ๆ ได้อีกด้วย ดังนั้นแต่ละทีมลองมาแบ่งปันแนวทางการออกแบบ API กันนะครับ ไม่ใช่แค่การออกแบบเท่านั้น ยังรวมไปถึงการสร้าง การทดสอบ การติดตั้ง และ ดูแลรักษา
↧

ปัญหาที่มักพบเจอกับระบบ Continuous Delivery ของ Mobile app

March 15, 2017, 10:15 am
$
0
0

ในการสร้างระบบ Continuous Integration และ Continuous Delivery สำหรับ Mobile นั้น มีหลายสิ่งอย่างที่ควรคำนึงถึง ไม่ว่าจะเป็น
  • จำนวนของ device ที่แตกต่าง
  • การออกแบบของแต่ละ platform
  • การพัฒนา
  • โครงสร้างของ code
  • การทดสอบ
  • การ deploy
  • การ release
โดยสิ่งที่เราต้องการคือ feedback loop ที่รวดเร็ว แน่นอนว่ามันย่อมรวดเร็วกว่าระบบอื่น ๆ อย่างมาก ดังนั้นสิ่งที่เราควรต้องทำการวางแผนงาน จากนั้นลงมือทำและสร้างมันขึ้นมาดังนี้

1. Testing นั่นคือการทดสอบ คำถามคือจะทดสอบกันอย่างไรบ้าง ?

เนื่องจาก Mobile มันซับซ้อนและหลากหลายนะ ทั้ง hardware และ software รวมทั้งระบบรอบข้างที่ Mobile app ต้องทำงานร่วมด้วย ทำให้การทดสอบจะเยอะและซับซ้อนมาก ๆ คำถามที่ตามมาคือ เรายังสามารถทดสอบแบบเดิม ๆ หรือ manual ได้หรือไม่ ? ถ้าได้ แล้ว feedback loop มันเร็วเพียงใด !! ดังนั้นสิ่งที่ขาดไม่ได้เลยคือ Automation testing จะแบ่งออกเป็นสองส่วนคือ
  1. ส่วนที่ทดสอบได้เร็ว นั่นคือไม่จำเป็นต้องใช้ device/emulator เพื่อทดสอบในแต่ละส่วนว่าทำงานได้ตามที่คาดหวัง
  2. ส่วนที่ทดสอบได้ช้า แต่ต้องการทำให้แน่ใจว่าทำงานบน device/emulator จริง ๆ ได้

2. จำนวน Branch ของ code

สิ่งที่ควรคำนึงมาก ๆ คือ จำนวน branch ของ code เช่นจะใช้ branch เท่าไร และอย่างไรบ้าง เช่นแยก branch ตาม device เช่น mobile และ tablet เป็นต้น เพื่อทำให้การดูแลรักษาง่ายขึ้น หรือจะแยกตาม feature !!
ยิ่ง branch มากขึ้นเท่าไร การดูแลรักษาจะยากขึ้นมากเท่านั้น

3. โครงสร้าง code เอื้อต่อการทดสอบหรือไม่ ? (Testable app)

ข้อนี้จำเกี่ยวข้องกับข้อ 1 อย่างมากซึ่งมีการทดสอบ 2 ส่วน ลองคิดดูสิว่า ถ้าโครงสร้างของ code ไม่เอื้อต่อการทดสอบ การทดสอบแบบอัตโนมัติก็ยากมาก ๆ ถึงทำไปก็ไร้ประโยชน์หรือมีน้อยมาก ๆ ดังนั้นสิ่งที่ควรให้ความสนใจคือ Testable app การแยกส่วนการทำงานออกเป็นส่วน ๆ แต่ละส่วนสามารถทดสอบได้ง่าย ดังนั้นขึ้นการ pair programming และ code review จึงขาดไม่ได้ เพื่อปรับปรุง feedback loop ให้รวดเร็วขึ้น

4. Environment ที่เกี่ยวข้องสนับสนุนหรือไม่ ?

แน่นอนว่า Mobile app มักจะต้องทำงานร่วมกับระบบอื่น ๆ และระบบต่าง ๆ เหล่านี้มักก่อให้เกิดปัญหาตามมามากมาย ตัวอย่างเช่น สามารถทดสอบซ้ำ ๆ ได้หรือไม่ ? ใช้เวลาในการ setup ข้อมูลสำหรับการทดสอบนานหรือไม่ ? นั่นคือระบบต่าง ๆ เอื้อต่อ Automation test หรือไม่ ? ถ้าไม่ นั่นคือปัญหาที่ต้องแก้ไข เพื่อให้ได้รับ feedback ที่มีค่ายิ่ง

5. Automation Deployment

จากข้อ 1 ถึงข้อ 4 พูดเครื่องของ Internal quality ล้วน ๆ ดังนั้นเราต้องส่งมอบสิ่งที่พัฒนาขึ้นมา ออกไปยังผู้ใช้งานหรือลูกค้าให้รวดเร็วและบ่อย เพื่อให้เราได้รับ feedback จากผู้ใช้งานจริง ๆ ว่าสิ่งที่เราพัฒนาขึ้นมานั้นมีประโยชน์ หรือช่วยผู้ใช้งานอย่างไรบ้าง เพื่อนำมาปรับปรุงและแก้ไขต่อไป คำถามคือ ถ้ายังมาทำแบบ manual process จะไหวไหมนะ ? ถ้าคิดว่าไหวก็ทำไป !! แต่ผมคิดว่า เราน่าจะมาสร้างระบบที่ทำงานแบบอัตโนมัติกันให้มากขึ้นนะ เพื่อลดการทำงานซ้ำ ๆ เพื่อลดปัญหาเดิม ๆ ที่เกิดจากคน
คำถามคือ คุณพร้อมที่จะปรับปรุงหรือไม่ ? ลงมือทำเถอะครับ จะรออะไรอยู่
↧
↧

สวัสดีกับ Create React Native App กันหน่อย

March 16, 2017, 7:33 am
$
0
0

ทางทีมพัฒนาของ Facebook และ Expo ร่วมมือกันพัฒนาเครื่องมือชื่อว่า Create React Native App ซึ่งได้รับแรงบันดาลใจมาจาก Create React App มีเป้าหมายเพื่อช่วยลดปัญหาในการสร้าง project และ configuration ต่าง ๆ ทำให้ชีวิตนักพัฒนาง่ายขึ้น ที่สำคัญ Create React Native App นั้น ไม่จำเป็นต้องติดตั้ง Xcode และ Android Studio ด้วยนะ ดังนั้นถ้าเรามี device สำหรับทดสอบ ก็สามารถพัฒนาบนระบบปฏิบัติการอื่น ๆ นอกจาก MacOS ได้ เพราะว่า code ต่าง ๆ เราจะเขียนด้วย node.js ทั้งหมด แต่ในการใช้งานจำเป็นต้องติดตั้ง Expo client app ใน device ด้วย

มาเริ่มใช้งานกันดีกว่า

ทำการติดตั้งและใช้งานด้วยคำสั่งดังนี้ [code] $npm i -g create-react-native-app $create-react-native-app helloworld $cd helloworld $npm start [/code] คำอธิบาย ทำการสร้าง project ชื่อว่า helloworld ซึ่งจะทำการ download dependency/library จำนวนมากมาย !! จากนั้นทำการ start development server ขึ้นมา ซึ่งสามารถเปิดทดสอบผ่าน Expo client app จะมี QR code หรือพิมพ์ url แบบตรง ๆ เลยก็ได้ ทำการทดสอบแบบ On-the-fly เลย แต่ต้องอยู่ในวง network เดียวกันนะ ที่สำคัญเมื่อเปลี่ยนแปลง code แล้ว App จะเปลี่ยนตามทันที (Hot reload) !! ดังรูป เมื่อทำการเปลี่ยนแปลง code แล้วผลการทำงานจะเปลี่ยนแปลงทันที ตัวอย่าง source code [gist id="2d6cb531e2c1d6fabaaaae4e60712bb7" file="App.js"] ลองดู log การทำงานได้ เช่น แสดงผลการทำงานใน Expo client app ดังรูป แต่ถ้าเขียน code ผิดขึ้นมา ก็จะแสดง error ดังนี้ Create React Native App เป็นเครื่องมือ ที่ทำให้ง่ายต่อการพัฒนาระบบอย่างมาก และยังใช้คำสั่งอื่น ๆ ได้นะ และสนับสนุน เช่น [code] $npm run ios //ต้องการ Xcode $npm run android //ต้องการ Android build tool $npm test //สำหรับการทดสอบตามชุดการทดสอบที่มี [/code] สามารถอ่านรายละเอียดเพิ่มเติมได้จาก https://github.com/react-community/create-react-native-app https://docs.expo.io/versions/latest/sdk/index.html
↧

รายชื่อเครื่องมือสำหรับ Automated Deployment

March 18, 2017, 8:13 pm
$
0
0

จากบทความเรื่อง 21 Automated Deployment Tools You Should Know ทำการรวบรวมเครื่องมือสำหรับ Continuous Integration และ Deployment โดยแต่ละตัวจะทำงานแบบอัตโนมัติทั้งสิ้น แต่คนคือคนที่กำหนดว่าจะให้มันทำอะไร ดังนั้นความรู้และความเข้าใจของคนจึงสำคัญมาก ๆ มาดูกันว่ามีอะไรบ้าง ? ซึ่งมีทั้ง opensource, commercial, software package และ cloud service ดังนี้ ถ้าถามว่าเครื่องมือตัวไหนดี ? คำตอบคือไม่รู้สิ เครื่องมือเหล่านั้นตอบโจทย์ทาง business หรือไม่ ? เครื่องมือเหล่านั้นเข้ามาช่วยให้ดีขึ้นหรือแย่ลง ? เครื่องมือที่ดีจากอีกที่หนึ่ง ก็อาจจะไม่ดีสำหรับอีกที่หนึ่งก็ได้นะ !! ดังนั้นปัญหาหรือโจทย์ของคุณคืออะไร ?
↧
Search

ผลของ Developer Survey ปี 2017 จาก StackOverflow มาแล้วนะ

March 22, 2017, 9:11 am
$
0
0

ในปี 2017 นี้ทาง Stackoverflow ได้จัดทำผลการสำรวจจาก developer ทั้งหลาย ปีนี้มีจำนวนมากกว่า 64,000 คนจากทั่วโลก แน่นอนว่ามีจำนวนเยอะกว่าปีที่ผ่าน ๆ มา โดยผลการสำรวจได้ผลออกมาดังนี้

Developer ที่ทำแบบสำรวจมาจากไหนกันบ้าง ?

โดยส่วนใหญ่จะเป็น Web Developer มากถึง 72.6%

เมื่อลงไปดูในรายละเอียดพบว่า ถ้าเป็น Web developer จะมี Full stack developer 63% ถ้าเป็น Mobile developer จะมี Android และ iOS พอ ๆ กัน ที่น่าสนใจคือเพศชายมีมากกว่า 88%

ส่วนภาษาโปรแกรมที่ได้รับความนิยมยังเป็น JavaScript, SQL, Java, C#, Python, PHP และ C/C++

โดยที่ JavaScript ยังคงครองที่หนึ่งมาถึง 5 ปีซ้อน ส่วน framework ก็หนีไม่พ้น Node.js, Angular, .Net Core และ React

มาดู Database ที่ได้รับความนิยมยังคงเป็น MySQL

ตามมาด้วย SQL Server, SQLite, PostgreSQL, MongoDB และ Oracle

ส่วน Platform ที่ใช้งานสำหรับการพัฒนา หลัก ๆ ยังเป็น Windows

ตามมาด้วย Linux, Android, AWS, MacOS, iOS และ Raspberry Pi

มาดูว่า developer ชอบ ไม่ชอบ หรือเกลียดภาษาโปรแกรมอะไรกันบ้าง ?

เริ่มต้นด้วยภาษาที่ developer เกลียดมาก ๆ คือ VB นั่นเอง !! รองลงมาก็พวก VBA, CoffeeScript, VB.Net, Matlab และ Objective-C ตามลำดับ ส่วนภาษาที่ชอบมาก ๆ คือ Rust, Smalltalk, TypeScript, Swift, Go, Python, Elixir, C#, Scala และ Clojure แต่ส่วนที่น่าสนใจกว่าคือ ภาษาโปรแกรมที่มีความต้องการมาก ๆ คือ Python ตามมาด้วย JavaScript, Go, C++, Java, TypeScript และ C# นั่นคือมุมมองของงานที่เกิดขึ้น

มาดูส่วน Framework/Library กันบ้าง ?

เกลียดสุด ๆ คือ Codova, Xamarin, Hadoop, Angular, Firebase, Spark ชอบสุด ๆ คือ React, Node.js, .Net Core, Spark, Firebase ส่วนสิ่งที่ต้องการคนมีความรู้ความสามารถมาก ๆ คือ Node.js, Angular, React และ .Net Core มันแปลก ๆ ดีนะ !!

มาดูส่วน Database กันบ้าง ?

เกลียดสุด ๆ คือ Oracle, SQLite, MySQL, Cassandra, SQL Server ชอบสุด ๆ คือ Redis, PostgreSQL, MongoDB และ SQL Server ส่วนสิ่งที่ต้องการคนมีความรู้ความสามารถมาก ๆ คือ MongoDB, PosgreSQL และ Redis

มาดูฝั่ง Platform กันบ้าง ?

เกลียดสุด ๆ คือ SharePoint, Salesforce, Wordpress ชอบสุด ๆ คือ Linux, Serverless, AWS, Raspberry Pi, Mac OS ส่วนสิ่งที่ต้องการคนมีความรู้ความสามารถมาก ๆ คือ Android, AWS, Raspberry Pi และ iOS นี่มันมี Mobile และ Cloud จริง ๆ

สิ่งที่ชอบอีกอย่างคือ รูปแสดงความเกี่ยวข้องของเทคโนโลยีต่าง ๆ

ช่วยทำให้เห็นภาพรวมเยอะเลย

Developer ทำการ check in code บ่อยไหม ?

กว่า 50% บอกว่าหลายครั้งต่อวันนะ

ในการประเมินผลการทำงานของ Developer ควรใช้อะไรดี ?

กว่า 70% บอกว่าต้องใช้ความพึงพอใจของลูกค้าเป็นหลักสิ

ปิดท้ายด้วย Development Practice กันดีกว่า

เรื่องที่ 1 รูปแบบในการพัฒนาหลัก ๆ คือ Agile, Scrum, Pairing และ Kanban  เรื่องที่ 2 Version Control หลัก ๆ คือ Git, Subversion, Team foundation server ที่เหลือคือไม่ใช้ !! เรื่องที่ 3 การใช้งาน Tab กับ Space พบว่า Tab ชนะนะ เรื่องที่ 4 แล้วสภาวะแวดล้อมแบบไหนเหมาะกับการเขียน code พบว่าอันดับหนึ่งคือ เปิดเพลงบ้างเถอะนะ ขอร้อง รองลงมาคือ ขอห้องเงียบ ๆ !!
ไปอ่านรายละเอียดเพิ่มเติมได้ที่ Developer Survey 2017 
↧

เรื่องขำ ๆ ของ Object-Oriented Programming !!

March 26, 2017, 8:12 pm
$
0
0

เช้านี้เจอฝนตกเข้าไป รถติด ทำงานสายกันทุกคน ขณะรถติดเจอภาพขำ ๆ ฮา ๆ เกี่ยวกับ Object-Oriented Programming (OOP) ซึ่งตอนเรียนกับตอนทำงานจริง ๆ มันแตกต่างกันโดยสิ้นเชิง ดังรูป เมื่อเราเรียนหรือคุยกันเรื่อง OOP เป็นดังรูป แต่เมื่อทำงานจริง ๆ กลับเป็นดังรูป คุณคิดว่ามันจริงไหม ?
↧
↧

สิ่งที่น่าสนใจใน Technology Radar Vol. 16 จาก Thoughtworks

March 28, 2017, 5:21 am
$
0
0

มาดูผลจาก Technology Radar Vol. 16 ของบริษัท Thoughtworks มาดูว่ามีเทคโนโลยีและเครื่องมืออะไรที่น่าสนใจบ้างและแนวโน้มต่าง ๆ ว่ามีอะไรที่ควรนำมาใช้ ว่ามีอะไรบ้างที่ควรลองมาใช้ ว่ามีอะไรบ้างที่ควรทำความเข้าใจก่อน ว่ามีอะไรบ้างที่ควรเลิกใช้หรือใช้อย่างระมัดระวัง มาดูกันเลยดีว่า

1. เรื่อง Techniques

เทคนิคที่แนะนำให้นำมาใช้งานได้เลยคือ Pipeline as code ซึ่งช่วยทำให้ทีมสามารถสร้างระบบการทำงานแบบอัตโนมัติ บนแต่ละ environment ได้ง่ายและสะดวกมากยิ่งขึ้น ด้วยการเขียน code ส่วนสิ่งที่แนะนำให้ลองมาใช้งาน ประกอบไปด้วย API as a product และ Serverless architecture ยังไม่พอนะ มีเทคนิคใหม่ ๆ เพิ่มเข้ามาอีกด้วยเช่น
  • การแยกข้อมูลที่เป็นความลับออกจาก source code
  • Legacy in a box นั่นหมายความว่า ถ้าสามารถสร้าง image ของ legacy system ได้ ก็น่าจะช่วยให้การพัฒนาดีและเร็วขึ้น
  • Progressive Web Application (PWA)
ปิดด้วยเทคนิคที่ไม่ควรใช้หรือใช้อย่างระมัดระวัง ประกอบไปด้วย  (Enterprise ล้วน ๆ) !!
  • การใช้ CI server เดียวกับทุก ๆ ระบบ
  • การทำ integration test บนระบบที่ใหญ่ ๆ (Enterprise) หรือ dependency สูง เพราะว่าเสียทั้งเวลา ค่าใช้จ่ายที่สูง แต่กลับได้ประโยชน์น้อยมาก ๆ ดังนั้นสิ่งที่ต้องทำแยกส่วนการทำงานเป็น component ย่อย ๆ จากนั้นทำเรื่อง Contract testing, แยก deploy แต่ละ component ได้ ลดเวลาในการ deploy และลดเวลาในการ recovery ระบบ
  • Spec-based code gen สิ่งที่เจอมาก ๆ คือ WSDL file นั่นเอง หรือ WebService !!! ทำให้การ maintain ลำบากมาก ๆ ลด ละ เลิกเสียนะ

2. เรื่อง Platforms

มีสิ่งที่น่าสนใจพอสมควร แต่จะอยู่ในกลุ่มที่แนะนำให้ลองนำมาใช้งาน เช่น
  • AWS Device Farm ใช้สำหรับการทดสอบ Mobile app บน device จำนวนมาก ๆ ซึ่งเป็นสิ่งที่จำเป็นมาก ๆ ในปัจจุบัน
  • OpenTracing เมื่อเข้าสู่ยุคของ microservice เรื่องของ monitoing/tracing พวก request การใช้งานต่าง ๆ จึงสำคัญมาก ๆ โดยที่ OpenTracing คือมาตรฐานกลางซึ่งพัฒนาโดย Uber, Apple, Yelp
ส่วนสิ่งที่น่าสนใจและยังต้องศึกษากัน ประกอบไปด้วย
  • api.ai
  • Hyperledger, Etherium
  • พวก VR มาเยอะเลยทั้ง OpenVR และ WebVR
สิ่งที่แนะนำให้ ลด ละ เลิก คือ การใช้ API gateway ที่มากหรือซับซ้อนเกินไป เพราะว่ายากต่อการทดสอบและ deploy อย่างมาก

3. เรื่อง Tools

เรื่องของเครื่องมือมีสิ่งที่แนะนำให้นำมาใช้งานเลยคือ
  • Fastlane ขาดไม่ได้เลยสำหรับระบบ Continuous Delivery ของ Mobile app ถ้าใครไม่ใช้ถือว่าบาปมาก ๆ
  • Grafana ช่วยทำให้การสร้างระบบ dashboard สำหรับ monitoring ระบบง่ายและสะดวกขึ้นอย่างมาก
สิ่งที่แนะนำให้ลองนำมาใช้งานมีเพียบเลยประกอบไปด้วย
  • Cake and Fake  เป็น build tool สำหรับภาษา C# และ F# ซึ่งเขียนด้วย DSL ที่ง่าย ซึ่งปีที่ผ่านมาได้รับความนิยมสูงขึ้นอย่างมาก น่าลองมาก ๆ
  • Serverless framework  เป็นเครื่องมือช่วยให้การ deploy และทำงานกับ AWS Lambda ได้ง่ายขึ้น รวมทั้งยังสนับสนุน platform อื่น ๆ อีกด้วย
  • Scikit-learn ก็ยังอยู่ในกลุ่มนี้นะ

4. เรื่อง Languages and Frameworks

มาถึงเรื่องสุดท้ายคือภาษาโปรแกรมและ framework ต่าง ๆ ในส่วนที่แนะนำให้นำไปใช้งานยังไม่มีอะไรใหม่ คือ Ember.js, Python 3, ReactiveX และ Redux ส่วนภาษาและ framework ใหม่ ๆ ที่ยังต้องศึกษาต่อไปปนะกอบไปด้วย
  • Angular 2 ต้องเรียกว่า Angular นะ
  • Kotlin
  • สาย Deep learning เช่น Caffe, DeepLearning.scala และ Knet.jl
  • Spring cloud
ส่วน AngularJS ก็ ลด ละ เลิกเถอะนะ !!
อ่านเพิ่มเติมได้ที่ PDF
↧

บันทึกการเตรียม Server ให้กับค่าย Give&Take Agile for Software Development Workshop

March 29, 2017, 9:35 am
$
0
0

มีโอกาสไปร่วมแบ่งปันความรู้ในการพัฒนา software ในค่าย Give&Take Agile for Software Development Workshop 3 วัน ให้กับนักศึกษาที่มหาวิทยาลัยขอนแก่น สิ่งที่ต้องจัดเตรียมให้คือ Server สำหรับการพัฒนาระบบจำนวน 10 กลุ่ม จึงทำการบันทึกไว้นิดหน่อย ปล. มีเวลาให้ทำประมาณ 30 นาทีได้มั้ง

มี software ต่าง ๆ ดังนี้

  • ระบบปฏิบัติการคือ Linux
  • ระบบพัฒนาด้วยภาษา Java 8
  • Web application server เลือกใช้ Apache Tomcat
  • ฐานข้อมูลคือ MySQL

ส่วนการพัฒนาและการ deploy ตกลงไว้ดังนี้

  • Source code ต่าง ๆ จะถูกจัดเก็บใน Github
  • ในการ deploy ระบบงานเพียงนำ WAR file ไปวางยัง directory ที่กำหนด
  • จากนั้นระบบงานจะทำการ auto deploy เอง

โดยเครื่องมือและ platform ที่เลือกใช้มีดังนี้

  • เลือกใช้งาน Cloud platform ที่ Digital Ocean
  • เลือกใช้ Docker สำหรับจัดการเรื่อง provisioning OS และ Software ต่าง ๆ
เมื่อทุกอย่างพร้อมก็ลงมือกันเลย

ขั้นตอนที่ 1 เลือก Image ที่ต้องการจาก Docker Hub

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

ขั้นตอนที่ 2 มาสร้าง container ต่าง ๆ จาก image

เริ่มจาก MySQL container ก่อนเลย ต้องทำการกำหนด user และ password สำหรับการเข้าใช้งาน ตลอดจนชื่อ database ดังนี้ [gist id="ea47312566dc3f850ecc36afe1788538" file="mysql.txt"] จากนั้นมาในส่วนของ Apache Tomcat ซึ่งเป็น Web Server สำหรับระบบงาน โดยตกลงกันว่าจะทำการ deploy ด้วย WAR file ตามชื่อที่กำหนด จากนั้นทำการ map path จาก Host กับ Container ซะ ส่วน port ที่ต้อง publish ออกมาจาก container และใช้งานผ่าน host ด้วยคือ 80 และที่สำคัญต้อง link หรือเชื่อมโยงไปยัง container mysql ได้ด้วยนะ ดังนั้นสามารถสร้าง container ได้ดังนี้ [gist id="ea47312566dc3f850ecc36afe1788538" file="tomcat.txt"] ต่อมาก็ทำการทดสอบว่าทุกอย่างมันทำงานได้ตามที่ต้องการหรือไม่ !!!

ขั้นตอนที่ 3 source code ต่าง ๆ นั้นอยู่ใน Version Control ซึ่งเลือกใช้ Github

โดยเพื่อความง่ายก็ตกลงกับทุก ๆ กลุ่มให้สร้าง WAR file แล้วเอาขึ้น GitHub ด้วย ฟังดูแล้วอาจจะไม่ดี แต่ผมคิดว่าน่าจะสะดวกสำหรับเวลาสั้น ๆ !!

ขั้นตอนที่ 4 เมื่อทุกอย่างพร้อมก็ลองบน Digital Ocean กันเลย

ปล. Account ที่ผมใช้งานนั้น สร้างได้แต่ 10 droplet เท่านั้น แต่ไม่เป็นไรก็ลองใช้ดูไปก่อน ความต้องการคือ ไม่อยากเข้าไปสร้าง Droplet เองผ่านหน้า web ดังนั้นขั้นตอนแรกต้องไปสร้าง Token สำหรับการ access ผ่าน API ก่อนดังรูป เมื่อได้มาแล้วก็มาเขียน script สำหรับการ provisioning ผ่าน Docker กัน เริ่มจากเครื่องเดียวก่อน มีขั้นตอนดังนี้ 1. ทำการสร้าง machine บน digital ocean ผ่าน docker-machine 2. ทำการ ssh เข้าไปยัง machine ที่สร้าง 3. จากนั้นทำการ clone source code จาก github.com 4. ทำการสร้าง container 2 ตัวคือ MySQL และ Apache Tomcat 5. ทำการเปิด firewall ให้เรียบร้อยคือต้องเปิด port 80 และ 22 ไว้ สามารถเขียนเป็น shell script แบบกาก ๆ ได้ดังนี้ [gist id="ea47312566dc3f850ecc36afe1788538" file="one_machine.sh"] ตรวจสอบผลการทำงานผ่านระบบตัวอย่างดังรูป
เมื่อสามารถสร้างเครื่องเดียวได้แล้ว ก็เขียน shell script เพื่อสร้าง 10 เครื่องต่อไป ...
ยังไม่พอ ต้องทำการดึง source code และ WAR file มา deploy บ่อย ๆ ดังนั้นจึงทำ process สำหรับการ pull code มาในแต่ละเครื่องอีก แน่นอนว่าใช้ crontab เลยจ้า สุดท้ายก็แจก username และ password สำหรับการเข้าใช้งานผ่าน shh ต่อไป ปิดท้ายเสียค่าใช้จ่ายสำหรับการเรียนรู้ครั้งนี้ไป 5 USD ถ้วน
↧

ขั้นตอนง่าย ๆ สำหรับการพัฒนาระบบงานด้วย ReactJS

April 1, 2017, 10:11 pm
$
0
0

ในการเริ่มต้นพัฒนาระบบ Web application ส่วนของ Front-end ด้วย ReactJS นั้น พบว่ายากต่อการเริ่มต้นอย่างมาก เนื่องจาก Ecosystem มันใหญ่มาก ๆ เนื่องจากต้องมีความรู้พื้นฐานเยอะมาก ๆ เนื่องจากมีเครื่องมือและ framework/library เยอะมาก ๆ โดยรวมแล้วยากมาก ๆ สำหรับมือใหม่ !! ชีวิตของ Front-end developer มันซับซ้อนอย่างมากมาย ดังนั้นจึงทำการสรุปขั้นตอนง่าย ๆ สำหรับผู้เริ่มต้นแบบผม ปล. ถ้าไม่เชื่อลองไปดู

1. แนะนำติดตั้ง Yarn ซะ

เป็นตัวจัดการ library หรือ dependency ต่าง ๆ ใน project แต่ถ้าตัวพื้นฐานที่ developer ทั่วไปจะใช้งานมาก่อนคือ NPM โดยการทำงานภายในของ yarn นั้นก็คือ NPM นั่นเอง แต่ทำการปรับปรุงการทำงานให้ดีและเร็วขึ้น ดังนั้นถ้าใช้คำสั่งของ yarn แล้วมีปัญหาสามารถสลับมาใช้ NPM ได้

2. ทำการติดตั้ง Create-react-app

การเริ่มต้นสร้าง project สำหรับการพัฒนาด้วย ReactJS นั้นไม่ง่ายเลย ต้องการความรู้ต่าง ๆ เยอะมาก ๆ ดังนั้นเพื่อความง่ายสำหรับการเริ่ม แนะนำให้ใช้งาน create-react-app ซะ เป็น command-line tool พัฒนาโดยทีมของ facebook นั่นเอง ปล. เมื่อเข้าใจการทำงานต่าง ๆ แล้ว ก็อย่าลืมมาสร้าง project เองด้วยนะ

3. ลงเมื่อเขียน code เพื่อสร้างระบบ

React นั้นไม่ได้เป็นเพียง View หรือ View template เท่านั้น ยังมีส่วนอื่น ๆ ที่แตกต่างและสำคัญมาก ๆ ซึ่งนั่นคือ React จริง ๆ ดังนั้นแนะนำให้ลงมือเขียน code เพื่อสร้างระบบงาน จะทำให้เข้าใจเรื่องต่าง ๆ ของ React แต่เริ่มจากระบบเล็ก ๆ ก่อนนะครับ ตัวอย่างเช่น เมื่อเริ่มต้นศึกษาและสร้างระบบงาน มักจะมีคนแนะนำให้ใช้ React Router เพื่อจัดการเรื่องของ routing ต่าง ๆ ของระบบ คำถามคือ ระบบเล็ก ๆ เราต้องการมันจริงหรือไม่ ? เราสามารถเขียนและจัดการเองได้หรือไม่ ? ในการเริ่มต้นแนะนำให้เขียนเองก่อน จากนั้นเมื่อเราเข้าใจ และ ระบบใหญ่ขึ้น ปัญหาจะเริ่มตามมา จึงให้นำ library/dependency ต่าง ๆ มาใช้เพื่อแก้ไขปัญหา
ปล. ต้องเข้าใจ และ พบปัญหาก่อนนำมาใช้นะครับ อย่าเอามาใช้ก่อนมีปัญหา
ดังนั้นจงให้เวลากับการคึกษาและลงมือเขียน React ให้มาก ๆ เพิ่ม library/dependency เท่าที่ต้องการจริง ๆ เท่านั้น แก้ไขปัญหาต่าง ๆ ด้วยตนเองก่อน จากนั้นจึงเริ่มไปศึกษา library ต่าง ๆ ว่ามีประโยชน์อะไร เช่น React Router และ Redux เป็นต้น
ที่สำคัญอย่าลืมเขียนชุดการทดสอบด้วยนะ ทั้ง unit test, routing test, service/integration test เป็นต้น

4. ทำการ deploy ระบบสิ

เมื่อพัฒนาระบบเสร็จแล้วไม่ว่าเล็กหรือใหญ่ก็ต้องทำการ deploy สิ เพื่อเรียนรู้ว่า เราจะทำการ deploy ระบบที่พัฒนาด้วย ReactJS อย่างไร ? เริ่มต้นจากการ build ด้วยคำสั่ง $yarn run build ซึ่งจะทำการ generate static file ต่าง ๆ ออกมาให้ โดยจะถูกสร้างอยู่ใน folder build นั่นเอง จากนั้นก็นำไฟล์ต่าง ๆใน folder นี้ไป deploy บน server ต่อไป ให้เริ่มจากการ deploy แบบ manual ก่อน จากนั้นให้เริ่มทำการ deploy แบบอัตโนมัติ เช่นการใช้ Surge เป็นต้น จะทำให้ชีวิตการพัฒนาสะดวกสบายขึ้นมาก

สุดท้ายแล้ว

ให้เริ่มด้วยระบบเล็ก ๆ ใช้ library/dependency เท่าที่จำเป็น เขียนชุดการทดสอบ สุดท้ายก็ทำการ deploy แบบอัตโนมัติอยู่ตลอดเวลา Reference Websites https://hackernoon.com/simple-react-development-in-2017-113bd563691f https://github.com/erikras/react-redux-universal-hot-example https://medium.com/javascript-scene/top-javascript-frameworks-topics-to-learn-in-2017-700a397b711 https://medium.freecodecamp.com/what-to-learn-in-2017-if-youre-a-frontend-developer-b6cfef46effd
↧
Viewing all 1997 articles
Browse latest View live
Search