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

ว่าง ๆ มาติดตั้ง Continuous Integration Server ใช้บนเครื่องด้วย Buildpal กัน

September 14, 2017, 9:27 am
$
0
0

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

แต่การติดตั้งมันก็ไม่ง่ายนะ

ติดปัญหามากมายทั้ง software ทั้ง CPU/RAM/Network รวมไปถึง configuration ชีวิตดูลำบากน่าดู จะติดตั้งระบบ Contunous Integration ก็แลดูจะนานไปหน่อย
ดังนั้นมาติดตั้งระบบ Continuous Integration บนเครื่องกันไปเลย แน่นอนว่านำ Docker มาใช้งานด้วย มาดูกันว่าใช้อย่างไร ?

ปัญหาที่ทำให้พบเจอเรื่อง Work on my machine

ประกอบไปด้วย
  • ในแต่ละ environment แตกต่างกัน
  • มีชุดการทดสอบนะ แต่ว่าเราคนจริงต้อง skip หรือบางคนลบทิ้งไป !!
  • มีหลาย ๆ ไฟล์ และ folder ที่มีเฉพาะในเครื่องของนักพัฒนา ขึ้นไปที่อื่นจะรอดได้ไง
  • ความผิดพลาดที่เกิดจาก code
ดังนั้นสิ่งที่ทีมพัฒนามักจะสร้างเพื่อแก้ไขหรือลดปัญหาเหล่านี้คือ การสร้างระบบ Continuous Integration ขึ้นมา เพื่อช่วยทำให้ทีมพัฒนารู้ตัวได้อย่างรวดเร็ว ว่ามีข้อผิดพลาดอะไรตรงไหน จะได้แก้ไขได้อย่างรวดเร็ว ที่สำคัญระบบนี้ตองทำงานได้อย่างรวดเร็ว

แต่เมื่อระบบเริ่มใหญ่ขึ้น

code เยอะขึ้น ทีมใหญ่ขึ้น เวลาในการทำงานของระบบ Continuous Integration ก็จะเริ่มช้าลง นั่นคือ เรารู้ปัญหาได้ช้าลง ซึ่งจำเป็นต้องแก้ไขเพื่อให้ทีมและนักพัฒนารู้ได้อย่างรวดเร็ว แน่นอนว่ามีวิธีการมากมาย เช่นการเปลี่ยนขั้นตอนการทำงาน เช่นการเพิ่ม RAM/CPU ให้เยอะและเร็วขึ้น

แต่มีอีกวิธีการหนึ่งที่น่าสนใจคือ

ทำ Local Continuous Integration Server บนเครื่องนักพัฒนาแต่ละคนไปเลย เพื่อทำให้นักพัฒนามั่นใจว่า สิ่งที่สร้าง แก้ไข หรือเปลี่ยนแปลงมันผ่านจริง ๆ นะ ก่อนนะทำการ push/checkin code มายังส่วนกลาง โดยการติดตั้งเราจะนำ Docker มาใช้ มันง่ายมากนะ โดยขั้นตอนของนักพัฒนาจะเปลี่ยนไป คือ
  • เมื่อทำการแก้ไข code บนเครื่องตาม requirement หนึ่ง ๆ แล้ว
  • เมื่อมั่นใจ ตรวจสอบสิ่งต่าง ๆ แล้ว ทำการ run Continuous Integration Server ที่เครื่อง
  • เพื่อทำการตรวจสอบสิ่งต่าง ๆ ทั้งการ compile, test
  • การทำงานต่าง ๆ อยู่ในโลกของ container
  • เมื่อทุกอย่างผ่านแล้ว ก็ทำการ commit/push/checkin code ไปยังส่วนกลางต่อไป
ซึ่งวิธีการนี้จะช่วยเพิ่มความมั่นใจให้กับนักพัฒนาขึ้นอย่างมาก ลดการ build ที่แดงหรือ fail ในระบบ Continuous Integration ที่อยู่ตรงกลางอีกด้วย แน่นอนว่า ส่งผลดีต่อทีมอย่างแน่นอน

ขี้โม้มากแล้ว มาลงมือทำกันบ้าง

ถ้าพูดเรื่องของระบบ Continuous Integration กันแล้ว มักจะพูดถึงแต่ Jenkins เนื่องจากเป้นเครื่องมือที่ได้รับความนิยม มี community ขนาดใหญ่ เอกสารเพียบ แต่จะติดตั้งและ configuration มันไม่ง่ายเลย ดังนั้นขอแนะนำของง่าย ๆ เล็กลงมาหน่อยคือ Buildpal โดยที่ Buildpal คือ Continuous Integration Server ที่สร้างมาในโลกของ container เลย ดังนั้นมันจึงต้องเล็กและเร็วเป็นธรรมชาติ สนับสนุนเรื่องของ Pipeline as a Code โดยที่ pipeline นั้นทำการเขียนด้วยภาษา JavaScript !! สามารถกำหนดให้ทำการแบบ sequence หรือ parallel ได้อีกด้วย แต่โชคไม่ค่อยดีว่า มันพัฒนาด้วยภาษา Java 8 นะ

รออะไรติดตั้งกันดีกว่า

ติดตั้งง่าย ๆ ผ่าน Docker ไปเลย โดยตัวอย่างทำการสร้าง Volume container ก่อน จากนั้นจึงทำการสร้าง container ของ Local Continuous Integration Server กัน ดังนี้ [gist id="4266b5ee456e09e06109f42636a7f8c6" file="install.txt"] ทดสอบด้วยการเปิด url http://localhost:8080/ ใน browser username=admin password=admin123

ต่อมาเริ่มสร้าง pipeline หรือขั้นตอนการทำงานกัน

สิ่งที่ต้องการเป็นดังนี้ 1. Source code ของ project อยู่ที่ Git repository 2. สร้าง Pipeline สำหรับการ compile + test ด้วย Apache Maven สามารถสร้างใน Buildpal ได้ดังนี้ 1. กำหนด Repository ก่อน สนับสนุน Git, File system และ Perforce ให้ทำการกำหนดค่าต่าง ๆ แสดงดังรูป 2. ทำการสร้าง Pipeline สิ่งที่กำหนดคือ เลือก Repository ที่ต้องการ เลือกใช้ image ที่ต้องการสำหรับสร้าง container จากนั้นก็เข้าไป execute คำสั่งต่าง ๆใน container กันแบบสบาย ๆ มาดูตัวอย่างของการใช้งาน Apache Maven เพื่อ compile + test ระบบแบบง่าย ๆ แสดงดังรูป 3. ผลการทำงานเป็นดังรูป โดยรวม ๆ แล้วก็ใช้งานง่ายดีนะ ทุกอย่างอยู่ในโลกของ container ด้วย Docker กันไปเลย ลองใช้กันดูนะครับ ไม่พอใจก็ลบ container ทิ้งไปซะ ง่ายสุด ๆ ดังนั้นเครื่องใครก็สามารถทำได้นะครับ ที่สำคัญถ้าทำ Image และไฟล์ต่าง ๆ ให้เหมือนกัน ก็จะไม่เกิดปัญหาเครื่องผมทำงานได้นะ !! ขอให้สนุกกับการ coding ครับ
↧
Search

ปัญหาจากการนำ DevOps มาประยุกต์ใช้งาน

September 15, 2017, 11:47 pm
$
0
0

จากบทความเรื่อง Why DevOps Efforts Fail ? เป็นเรื่องเกี่ยวกับปัญหาเมื่อนำเอา DevOps มาประยุกต์ใช้ จึงนำมาแปลและสรุปไว้นิดหน่อย เป้าหมายของ DevOps นั้นเรียบง่ายมาก ๆ คือ ส่งมอบ software ให้ราบรื่น ส่งมอบ software ให้รวดเร็ว ส่งมอบ software ที่มีความน่าเชื่อถือ ส่งมอบ software ที่มีคุณภาพ โดยที่องค์กรได้นำเอาแนวคิดนี้ไปประยุกต์ใช้งาน ซึ่งมักจะมีกรอบแนวคิดตาม CALMS (Culture, Automation, Lean, Measurement และ Sharing) ปัญหาที่ตามมาจากการประยุกต์ จะแบ่งออกเป็น 3 เรื่องใหญ่ ๆ
  • มีเครื่องมือเยอะมาก ๆ ไม่รู้จะนำมาใช้ รวมทั้งปัญหาเรื่องการเรียนรู้
  • ส่วนใหญ่ยังทดสอบระบบแบบ manual อยู่ ซึ่งทำให้การส่งมอบช้า
  • ระบบงานยังคงประกอบไปด้วยระบบใหม่และระบบเก่า ซึ่งทำให้มีความซับซ้อนสูง
  • ปัญหาเรื่องโครงสร้างขององค์กรที่ยังเป็นกลุ่มใครกลุ่มมัน ส่งผลให้การทำงานร่วมกันไม่ค่อยดี
  • มีปัญหาเรื่องของการเข้าถึง infrastructure ซึ่งมีความยุ่งยากมากมาย
  • ไม่ได้รับการสนับสนุนเท่าที่ควรจากฝ่ายบริหารจัดการ
มาดูรายละเอียดของปัญหากันหน่อยสิ

เครื่องมือมันจะเยอะไปไหน !!

ต้องยอมรับว่าเครื่องมือในโลกของ DevOps หรือ DevOps tool มันเยอะมาก ๆ เพื่อช่วยทำให้การทำงานแบบอัตโนมัติได้ง่ายขึ้น ทั้ง Source Control ทั้ง Continuous Integration ทั้ง Continuous Infrastructure/Provisioning ทั้ง Continuous Deployment ทั้ง Continuous Monitoring ทั้ง Configuration Management ทั้ง Release Management ปัญหาที่พบเจอคือ จะนำเครื่องมือเหล่านี้มาใช้ร่วมกันอย่างไร ? แสดงดังรูป

ขาดเรื่องของ Test Automation

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

ปัญหาในการจัดเตรียม environment และ infrastructure

เนื่องจาก environment มีความหลายหลายมาก ๆ ทั้ง physical server ทั้ง cloud มีทั้ง private, public และ hybrid cloud ทั้งโลกของ container และ virtual machine ซึ่งมีเทคโนโลยีที่หลากหลาย ยิ่งเมื่อกลับมาดูระบบงานที่มีความหลากหลายและซับซ้อน ทำให้ยากลำบากต่อการจัดเตรียม environment ต่าง ๆ ทั้ง Development, Test, UAT และ Production

อีกเรื่องคือ เรื่องของคนและ culture มันสำคัญมาก ๆ

ที่แต่ละฝ่ายต่างทำงานของใครของมัน Dev ก็พัฒนาไป QA ก็ทดสอบไป IT Operation ของ deploy และ operate ไป ต่างฝ่ายต่างมีเป้าหมายที่ต่างกัน ดังนั้นเมื่อนำคนเหล่านี้มาทำงานร่วมกัน ก็ยิ่งทำให้เกิดข้อขัดแย้งกันมากมาย ยิ่งเร่งก็ยิ่งช้า
ดังนั้นทำอย่างไรจึงจะลดปัญหาเหล่านี้ลงไปได้ ?
↧
↧

ว่าด้วยเรื่อง ลืม Configuration ของระบบงาน

September 17, 2017, 10:02 am
$
0
0

ก่อนอื่นนักพัฒนาน่าจะคุ้นเคยกับการจัดการเรื่องของ configuration ค่าต่าง ๆ ในระบบ ยกตัวอย่างเช่น
  • ข้อมูลสำหรับ database
  • ข้อมูลสำหรับ URL ของ service ต่าง ๆ
  • username และ password
บ่อยครั้งมักจะทำการ hardcode เอาไว้ใน source code !! ยกตัวอย่างเช่น [code] database_connect("dev.db.com", "admin", "admin") [/code]
สิ่งที่น่ากลัวคือ เรามักเจอว่า code เหล่านี้มันขึ้นไปยัง environment ต่าง ๆ รวมทั้ง production server  ด้วยเหตุผลง่าย ๆ สั้น ๆ ว่า ลืม !!

จากนั้นเริ่มแก้ไขปัญหาด้วยการแยกออกมาใส่ไฟล์ (Configuration file)

เป็นที่มาของ configuration file นั่นเอง เรามักจะเจอไฟล์ประเภทนี้ในหลากหลายรูปแบบและลีลา ทั้งแยกไฟล์ตามแต่ละ environment ทั้งไฟล์เดียวแต่มีการตรวจสอบค่า profile เช่น dev, test, prod เป็นต้น ทั้งเป็น application file ของระบบหรือ framework
แต่ปัญหาคำว่า ลืม ก็ยังตามมาหลอกหลอนอยู่ดี เพราะว่า ไฟล์เหล่านี้ยังอยู่ใน Source Control อยู่ดี และจัดการด้วยคน !!
ดังนั้นเราจึงแก้ไขปัญหาด้วยการห้าม commit/push/checkin ไฟล์เหล่านี้ขึ้นไป หรือทำการ ignore นั่นเอง เพื่อลดข้อผิดพลาดของนักพัฒนา หรือ กันลืม นั่นเอง แต่ปัญหามันก็ถูกส่งต่อไปให้คนที่ดูแลเรื่องการ deploy และ release อีก !!

จึงมีอีกแนวคิดหนึ่งคือ ก็ใช้ configuration เดียวกันในทุก ๆ environment สิ !!

ลองคิดดูสิว่า ถ้าทุก ๆ ส่วนมีค่าเหมือนกัน ตั้งแต่ local -> dev -> test -> uat -> staging -> production เราจะเสียเวลามาดูแลเรื่อง configuration กันไปทำไม แต่เมื่อพูดและบอกแบบนี้ไป ก็บอกว่า มันเป็นไปไม่ได้หรอกนะ เพราะว่า .... เพราะว่า .... เพราะว่า .... แต่ลองเปลี่ยนแนวคิดว่า เราจะทำให้ configuration ในทุก ๆ environment เหมือนกันสิ วิธีการมันก็เปลี่ยนไปแล้ว ใช่ไหม ?

จะเห็นได้ว่าปัญหามันเกิดจากคน ที่ดันลืม !!

แก้ไขปัญหาที่ต้นเหตุของปัญหากันดีกว่านั่นคือ คน ดังนั้นจึงมีแนวคิดเรื่องของ automation หรือการทำงานแบบอัตโนมัติ ทั้งเรื่องของ shell script และ เครื่องมือต่าง ๆ ยกตัวอย่างเช่น Dynamic configuration ตามแต่ละ environment ซึ่งถูกกำหนดไว้ใน environment variable เช่น [code] $NODE_ENV=production npm run build [/code] ทำให้สิ่งต่าง ๆ เริ่มดีขึ้น

แต่จะเห็นได้ว่า configuration ระหว่าง application กับ infrastructure ยังแยกกัน !!

ซึ่งทำให้เกิดปัญหาตามมาได้ ดังนั้นสิ่งที่ควรทำคือ infrastructure ควรมี configuration ต่าง ๆ ที่ application ต้องการใช้ให้ครบ และที่สำคัญ configuration ของทั้งคู่ควรอยู่ใน repository ของ Source control เดียวกัน แน่นอนว่ามีเครื่องมือมากมายให้ใช้งาน เช่น Docker, Ansible, Chef, Packer และ Terraform เป็นต้น ยกตัวอย่างเช่นการใช้งาน Docker สามารถสร้าง infrastructure ที่เหมือนหรือคล้ายกันให้กับระบบได้เลย [gist id="5096cc6bbd8accabcb414f3952408180" file="docker-compose.yml"] หรือจะให้ดึงข้อมูลจากไฟล์ configuration ที่กำหนดก็ mapping volume ไปก็จบละ

อาจจะมีปัญหาเรื่องของความลับของข้อมูล

เนื่องจากทำการเก็บข้อมูลไว้ใน configuration และ environment variable แต่ก็ไม่เป็นปัญหาอะไร เพราะว่ามีเครื่องมือให้ใช้นะเช่น

สุดท้ายแล้ว

การย้าย configuration ไปยัง environment variable การย้าย configuration ต่าง ๆ ไปรวมไว้ที่เดียวกัน มันไม่ได้ช่วยลดปัญหาเรื่อง การลืมได้ทั้งหมด ดังนั้นเรื่องของ configuration นั้นขอให้มีน้อยที่สุด มีเท่าที่จำเป็นเท่านั้น ดีที่สุดคือ ไม่มีนั่นเอง ขอให้สนุกกับการ coding ครับ
↧

ความสามารถที่น่าสนใจใน Kotlin 1.1.4

September 18, 2017, 12:10 am
$
0
0

ทางทีมพัฒนา Kotlin เพิ่งปล่อย Kotlin 1.1.4 ออกมาตั้งแต่วันที่ 15 เดือนสิ่งหาคม แต่ไม่มีเวลาดูเท่าไร ดังนั้นว่าง ๆ เลยมาสรุปความสามารถที่น่าสนใจกันหน่อย ประกอบไปด้วย
  • ปรับปรุงประสิทธิภาพการทำงานของ plugin ใน IntelliJ IDE มากมาย
  • ปรับปรุงเรื่องของ Java 9 เช่นเรื่อง modular เป็นต้น
  • ปรับปรุงการ generate bye code ให้มีประสิทธิภาพมากขึ้น
  • เพิ่มการตรวจ dead code ใน JavaScript เข้ามา รวมไปถึงของการ debug และ unit test ด้วย
  • เพิ่มความสามารถของ Android plugin เช่น ViewHolder, Build Variant และ Parcelable
  • สามารถเขียน Gradle script ด้วยรูปแบบ Kotlin-DSL ได้อีกด้วย
โดยการ update สิ่งต่าง ๆ ต้องเข้ากันได้กับ Android Studio 2.3 และ 3.0 Beta ด้วย ดูเพิ่มเติมได้ใน ChangeLog ซึ่งตอนนี้จัดไปถึง 1.1.4-3 แล้วนะ เร็วมาก ๆ โดยตัวที่น่าจะใช้บ่อย ๆ คือ Android plugin นั่นเอง อย่าง Parcelable ก็ไม่ต้องมานั่งเขียนหรือ generate เองแล้ว แต่มันยังอยู่ในช่วง experiment นะครับ ต้องระวังนิดหน่อย
ถ้าใครยังไม่รู้จักกับภาษา Kotlin แนะนำให้ลองที่ Try Kotlin นะครับ
ขอให้สนุกกับการ coding ครับ
↧

ความแตกต่างระหว่าง Method และ Computed property ใน Vue.js

September 19, 2017, 2:13 am
$
0
0

เช้านี้อ่านเจอการพูดคุยเรื่องของความแตกต่างระหว่าง Method และ Computed property ใน Vue.js ซึ่งเป็นความสามารถที่อาจจะทำให้สับสนได้ ดังนั้นมาดูรายละเอียด และ code ตัวอย่างกัน มาเริ่มกันเลย

Vue.js มันคือ reactive

หมายความว่า มันสามารถตอบสนองตอบกับเหตุการณ์ต่าง ๆ ได้แบบง่าย ๆ ทั้งที่เกิดจากผู้ใช้งาน เช่นกรอกข้อมูล กดปุ่ม เป็นต้น รวมทั้งข้อมูล (model)ในระบบมีการเปลี่ยนแปลง โดยใน Vue.js จะมี 3 component ให้ใช้งานคือ
  1. Method
  2. Computed property
  3. Watcher
ทั้งสาม component นี้ดูแล้วอาจจะคล้ายหรือเหมือนกัน แต่กลับเหมาะสมกับงานหรือ usecase ที่ต่างกัน ก่อนอื่นมาลองเขียน code เพื่อใช้งานทั้งสาม component กันดีกว่า เพื่อทำให้เห็นภาพและการใช้งานชัดเจนขึ้น

1. Method

มันคือพื้นฐานสุด ๆ ใช้เมื่อต้องการเปลี่ยนแปลงข้อมูลหรือกระทำต่าง ๆ กับ state หรือดักจับเหตุการณ์ต่าง ๆ จากผู้ใช้งาน โดยที่ method สามารถมีหรือไม่มี argument ก็ได้ และการ run method มักจะส่งผลต่อ component นั้น ๆ ตัวอย่างเช่นจะทำการ reload component เมื่อทำการ run method ซึ่งส่งผลต่อประสิทธิภาพของการทำงานมาก ๆ มาดูตัวอย่างการใช้งาน method กันบ้าง เป็นระบบการเพิ่มข้อมูลคะแนนของนักศึกษาเข้าระบบ ประกอบไปด้วย ชื่อ และ คะแนน เมื่อกรอกข้อมูลเสร็จแล้วให้กดปุ่มเพิ่มข้อมูล สามารถเขียน code ได้ดังนี้

2. Computed property

เราจะใช้เมื่อต้องการแก้ไขข้อมูลบางตัว ซึ่งผูกมัดกับข้อมูลอื่น ๆ จากตัวอย่างนั้น ถ้าผมต้องการหาค่าเฉลี่ยของคะแนน จะเปลี่ยนไปเมื่อมีการเพิ่มข้อมูลคะแนนของนักศึกษาเข้ามา ถ้าเกิดเหตุการณ์แบบนี้ เราสามารถนำ Computed property มาใช้ได้ เพื่อแยกส่วนการคำนวณออกไปจากส่วนการรับข้อมูลจากผู้ใช้งาน โดยที่ Computed property จะคอยตรวจสอบการเปลี่ยนแปลงให้เราเอง จากนั้นจะทำการเรียกหรือ trigger การทำงานให้เองแบบอัตโนมัติ หรือเราเรียก Computed property ว่า getter method นั่นเอง ถ้าข้อมูลที่เรากำลังดักจับการเปลี่ยนแปลง ไม่มีการเปลี่ยนแปลง ค่าของมันก็จะไม่เปลี่ยนหรือใช้ค่าล่าสุดที่เปลี่ยนนะครับ โดยที่ Computed property จะเป็น method ที่ไม่มี argument นะ หรืออาจจะเรียกว่า Observable property ก็ได้ ซึ่งผมชอบ feature นี้ตั้งแต่ภาษา Swift แล้ว ทำให้การดักจับการเปลี่ยนแปลงข้อมูลในระบบง่ายมาก ๆ มาดูตัวอย่าง code กันดีกว่า

3. Watcher

เป็นอีกตัวที่อาจจะทำให้สับสน โดยที่ watcher นั้นใช้งานหลังจากที่ข้อมูลเปลี่ยนแปลงเสร็จแล้ว ซึ่งจะทำการเรียกใช้งาน method ที่ต้องการได้เลย การทำงานใน watcher นั้นมักจะเป็นงานแบบ asynchronous หรือ งานที่ใช้ resource เยอะ ๆ ยกตัวอย่างเช่น หลังจากการเพิ่มข้อมูลคะแนนและแสดงผลค่าเฉลี่ยของคะแนนเสร็จแล้ว ต้องทำการบันทึกข้อมูลไปยัง Server หรือ เรียก REST APIs น่าจะพอทำให้เข้าใจที่สาม component ใน Vue.js มากขึ้นนะครับ ขอให้สนุกกับการ coding ครับ Reference Websites https://alligator.io/vuejs/computed-properties/ https://www.pointofvue.net/2017/04/19/vue-js-when-to-use-methods-computed-properties-or-watchers/ https://stackoverflow.com/questions/44350862/method-vs-computed-in-vue
↧
↧

คำตอบของ Dan Abramov จากคำถามใน HashNode

September 20, 2017, 1:12 am
$
0
0

วันนี้ Dan Abramov มาตอบคำถามใน HashNode เกี่ยวกับ 2 ปีที่ทำงานที่ facebook ว่าได้เรียนรู้อะไรบ้าง ? ดังนั้นจึงทำการแปลและสรุป รวมทั้งเพิ่มเติมไว้นิดหน่อย น่าจะมีประโยชน์สำหรับนักพัฒนากันบ้าง ข้อแรกเรื่องของทีม ของ manager ที่ดี ซึ่งทำให้ชีวิตการทำงานมันแจ่มมาก ๆ เรื่องคน เรื่องทีม เรื่อง manager เรื่องความไว้เนื้อเชื่อใจ มันสำคัญต่องานมาก ๆ เพราะว่างานที่ออกมามันก็สะท้อนทีมและองค์กรนั่นเอง ข้อสองเรื่อง Big rewrites often fail การเขียน code ใหม่จำนวนมาก ๆ มันมักจะ fail เยอะ ดังนั้นถ้าต้องการเขียนใหม่ แนะนำให้เขียนแบบค่อยเป็นค่อยไป เนื่องจากการเขียนใหม่ทั้งหมดนั้นเราคาดหวังว่าจะแก้ไขปัญหาได้ แต่มันมักจะสร้างปัญหาอื่น ๆ ตามมาอีกมากมาย ยิ่งถ้าคุณไม่ได้เขียน version ก่อนหน้านั้นมา ยิ่งไปกันใหญ่ ข้อสามเรื่อง Big rewrites can succeed ดูเหมือนมันจะขัดแย้งกับข้อสองน่าดู แต่ว่าจะเขียนได้นั้นก็ต่อเมื่อมีชุดของการทดสอบ เช่น integration test ที่ดี เน้นย้ำว่าดีนะ นั่นคือไว้ใจและเชื่อถือได้ รวมไปถึงวิธีการส่งมอบสิ่งที่สร้างไปถึงมือผู้ใช้งาน จะเห็นการเขียนใหม่ได้จาก React 16 ข้อสี่ สำหรับ library ต่าง ๆ ที่นำมาใช้งานควรต้องเขียนชุดการทดสอบระดับ public api สำหรับการทดสอบนั้น ต้องช่วยว่าระบบมันทำงานได้อย่างถูกต้อง รวมทั้งต้องง่ายต่อการเปลี่ยนแปลงอีกด้วย เช่นการเปลี่ยน library เป็นต้น ดังนั้นการทดสอบก็ต้องคิดให้มากเช่นกัน Unit testing มันดีแต่ใช้ให้เหมาะสม ข้อห้า สำหรับ code ที่ซับซ้อนมาก ๆ แนะนำให้ทดสอบแบบ fuzz testing !! อย่างแรกเลย Fuzz testing มันคืออะไร ? จาก Wikipedia อธิบายไว้ว่า มันคือวิธีการทดสอบที่จะเตรียมข้อมูลที่ invalid, unexpected และ random ขึ้นมา จากนั้นทำการดูการทำงานของระบบว่า จะพังหรือไม่ ? memory leak หรือไม่ ? การทดสอบพังหรือไม่ ? จากข้อมูลเข้าที่เราไม่ได้คาดคิด อาจจะส่งผลให้เกิดผลลัพธ์ที่ไม่คาดฝันขึ้นมาได้ ข้อหก เกี่ยวกับ code ที่เขียนให้คิดว่า สิ่งที่สร้างขึ้นมามันจะพัฒนาต่อไปอย่างไร ? นั่นคืออย่าคิดเพียงว่าปัจจุบันเป็นอย่างไร ให้คิดถึงอนาคตที่ต้องเป็นไปด้วย นั่นคืออย่าเขียนเพียงให้มันเสร็จ ๆ การเขียน code แต่ละทางมันมีทั้งข้อดีและข้อเสีย สิ่งที่เราต้องทำอยู่ตลอดเวลาคือ การคิดและตัดสินใจ ซึ่งมันอาจจะดีหรือไม่ดีก็ได้ เพราะว่าผลที่ตามมาคือ อาจจะทำให้คุณไปถึงหรือไม่ถึงเป้าหมายได้ ดังนั้น คิดนะ Think about code in time ข้อเจ็ด เราไม่จำเป็นต้องรู้ทุกสิ่งอย่าง แต่เราจำเป็นต้องรู้และเข้าใจเป้นอย่างดีเมื่อต้องเข้าไปยุ่งเกี่ยวกับส่วนนั้น นั่นคือ เราต้องเรียนรู้เพื่อเข้าใจในสิ่งที่ไม่เข้าใจนั่นเอง ข้อสุดท้ายเรื่องวิธีการคิดที่เป็นระบบ เมื่อเกิดปัญหาเรามักจะเข้าไปไล่อ่าน code แบบ sequencial ไปเรื่อย ๆ ซึ่งเป็นวิธีการที่ไร้ประสิทธิภาพและเสียเวลาไปอย่างมาก ดังนั้นสิ่งที่เราควรคิดคือ เราจะมีวิธีการจัดการมันอย่างไร ยกตัวอย่างเช่นมีปัญหาระหว่าง A ไปยัง B การแก้ไขลองเขียน log ตรงกลางระหว่าง A กับ B ก่อน เพื่อดูว่ามีข้อผิดพลาดของการส่งข้อมูลบางชุดหรือไม่ก่อน ? ซึ่งมันช่วยตัดไปหาไปได้เยอะหรือสักครึ่งนึงแล้ว จากนั้นจึงไปดูอีกฝั่งต่อไป มันจะช่วยทำให้การ debug และหาข้อผิดพลาดได้ดีขึ้นมาก
นั่นคือ Observe -> form a hypothesis -> come up with a way to test it -> repeat
และอะไรก็ตามที่มันซับซ้อนหรือเยอะมาก ๆ ให้แบ่งครึ่งก่อนนะ ในข้อนี้พูดง่าย แต่ทำไม่ง่ายเลย มาถึงตรงนี้น่าจะทำให้เราเห็นหลาย ๆ อย่างเลยนะครับ เพื่อนำมาปรับใช้งานกันต่อไป  
↧

วันนี้นักพัฒนาเขียน TODO และ FIXME ใน code แล้วหรือยัง ?

September 20, 2017, 6:43 am
$
0
0

วันนี้นั่งดู code ช่วงบ่ายในขณะที่ฝนกำลังถล่ม กทม เจอชุด comment ที่น่าสนใจ ซึ่งนักพัฒนาทุกคนน่าจะเคยเห็นผ่านตามาแล้ว ทั้งเกิดจากการ generate แบบอัตโนมัติจาก IDE ทั้งเขียนจากคนอื่น รวมทั้งตัวเราเองด้วย นั่นคือ TODO และ FIXME คำถามที่น่าสนใจคือ
  • มันคืออะไร ?
  • เขียนไว้ทำไม ?
  • ทำไมไม่มีใครมาลบมันออก ?
มาหาคำตอบกัน

TODOs มันมีไว้เพื่อบอกว่า

ตรงไหนที่เรากำลังทำหรือแก้ไขอยู่นั่นเอง ตรงไหนที่เรายังทำไม่เสร็จ FIXME มันมีไว้เพื่อบอกว่า code ส่วนไหนที่มีข้อผิดพลาด เพื่อทำให้มันดีขึ้น หรือ ทำให้ถูกต้อง ที่สำคัญบรรดาเครื่องมือ และ IDE/Editor ต่าง ๆ ยังสนับสนุนอีกด้วย นั่นหมายความว่า เขียนไว้ตรงไหนแล้ว IDE จะทำการสรุปรวมไว้ให้ ซึ่งมันน่าจะเป็นสิ่งที่ดีมาก ๆ

แต่เมื่อเวลาผ่านไป เราจะพบว่า

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

สุดท้ายด้วยคำถามง่าย ๆ ว่า

วันนี้คุณมี TODO และ FIXME แล้วหรือยัง ? มีใครไปลบ TODO และ FIXME ใน code ทิ้งไหม ? ระบบงานที่คุณพัฒนามีจำนวนของ TODO และ FIXME ใน code จำนวนเท่าไร ? ขอให้สนุกกับการ coding ครับ
↧

[Robotframework] Selenium2Library มันกลับไปรวมกับ SeleniumLibrary แล้วนะ

September 20, 2017, 11:07 pm
$
0
0

วันนี้เข้าไปที่ Selenium2Library แล้วพบว่า ตั้งแต่ version 3.x ขึ้นมานั้นจะเปลี่ยนไปใช้ชื่อ SeleniumLibrary แทน โดยที่ประวัติของ library ทั้งสองอาจจะตลกหน่อยคือ Selenium2Library นั้นถูก fork มาจาก SeleniumLibrary เนื่องจาก SeleniumLibrary ยังผูกติดกับ Selenium version 1 แต่เมื่อวันเวลาผ่านไปทั้งสองกลับมารวมกันใหม่
Selenium2Library is a web testing library for Robot Framework that uses the Selenium tool internally. Starting from version 3.0, the library is renamed to SeleniumLibrary and this project exists mainly to help with transitioning.
SeleniumLibrary ใหม่นี้คือ SeleniumLibrary 3.0 ตอนนี้อยู่ในสถานะ beta version อยู่ คือ beta 1 เท่านั้น ดังนั้นรอต่อไปอีกนิดนึงนะเออ !! ส่วน Selenium2Library นั้นมันมี 2 version หลักคือ
  • 3.x จะสนับสนุนทั้ง Python 2.7 และ 3.x
  • 1.8 จะสนับสนุนเพียง Python 2.6 และ 2.7 เท่านั้น
ขอให้สนุกกับการ coding นะ
↧
Search

Java 9 :: สิ้นสุดการรอคอยอันยาวนาน

September 22, 2017, 8:10 am
$
0
0

เป็นการรอคอยที่ยาวนานมาก ๆ สำหรับ Java 9 หลังจากที่ Java 8 ปล่อยออกมาเมื่อ 3 ปีที่แล้ว !! ดังนั้นมาดูกันหน่อยว่า มี feature หลัก ๆ อะไรกันบ้าง ? มีอะไรที่เปลี่ยนแปลงกันบ้าง ? มาดูกันเลย

สิ้นสุดการรอคอยที่ยาวนานสำหรับ Project Jigsaw

ซึ่งมีแผนจะออกมาตั้งแต่ Java 7 !! แต่ก็ติดโรคเลื่อนมาตลอด เพราะว่าไม่ผ่านการลงมติของ JCP committee ด้วยเหตุผลทางด้านการพัฒนาและเรื่อง compatibility กับ code เก่า ๆ แต่ใน Java 9 ก็ออกมาแล้ว มันคือ การเปลี่ยนแปลงครั้งสำคัญของ Java กันเลยทีเดียว ทำให้ Java เป็น modular ง่ายขึ้น อีกทั้งยังช่วยลดขนาดของ JRE ลงอีกด้วย รวมทั้งสามารถ custom เฉพาะสิ่งที่ต้องการใช้อีกด้วย อะไรที่ไม่ใช้ก็เอาออกไป

ดังนั้นแนวทางการพัฒนาและเขียน code จึงต่างออกไป

แน่นอนว่านักพัฒนาก็ตั้งศึกษาและปรับตัวด้วยเช่นกัน ทั้งแนวคิด modular ทั้ง jshell หรือ Java + REPL (Read Eval Print Loop) ทั้งสนับสนุน Reactive Stream ทั้ง Concurrency API ทั้ง StackWalker API ทั้ง Process API ทั้งสนับสนุน HTTP 2.0 รวมทั้งการ debugging บน production !! เยอะน่าดูนะ แต่มีเยอะกว่านี้ ส่วนที่แอบเสียใจคือ lightweight JSON API, Money API และ Currency API ที่ไม่มีใน Java 9 แต่ก็แอบหวังว่าใน Java 10 มันน่าจะมี

หลังจากนี้รอบการ release หลักในทุก ๆ 6 เดือน

นั่นคือเป็นการ fixed date release หรือ time-driven ซึ่งเป็นการเปลี่ยนแปลงครั้งสำคัญจาก feature-driven ส่วนการ update จะเป็นทุก ๆ quarter

สุดท้ายแล้ว

Java 9 นั้นมี feature ใหม่ ๆ มากมาย รวมทั้งเปลี่ยนแปลงวิธีการเขียน code ไปอย่างมาก จึงเป็นงานที่ยากพอสมควร แต่ก็น่าจะต้องลงมือทำกัน ทั้งการอ่านเอกสารพวก specification, requirement และ feature ต่าง ๆ ที่สำคัญ Download กันเลยสิ รออะไรอยู่ Java SE 9
↧
↧

ความเข้าใจผิดเกี่ยวกับ Unit test คือทำแล้วไม่มี Bug !!

September 24, 2017, 8:51 am
$
0
0

เมื่อหลายวันก่อนพูดคุยเกี่ยวกับ Unit testing เลยได้มีโอกาสแลกเปลี่ยนมุมมองต่อการเขียนและการนำมาใช้งานนิดหน่อย ซึ่งสิ่งหนึ่งที่น่าสนใจคือ ความเข้าใจผิด ยกตัวอย่างเช่น
  • ถ้าเรามี Unit tests แล้ว bug ของระบบจะไม่มี
  • ถ้าเรามี Unit tests แล้วคุณภาพของระบบต้องดีแน่ ๆ รวมทั้ง code ด้วย
  • ถ้า Unit tests มันไม่มีประโยชน์อะไร ก็ไม่ต้องทำ
เลยนำมาอธิบายไว้นิดหน่อย

คิดว่ามี Unit tests แล้วระบบต้องไม่มี bug !!

ระบบที่ทุกคนต้องการคือ ระบบที่ทำงานได้อย่างถูกต้อง ระบบที่สามารถจัดการกับเหตุการณ์ที่คาดไม่ถึงได้ คงไม่มีใครชอบระบบที่มี bug หรือข้อผิดพลาดมากมาย ดังนั้นสิ่งที่ทีมพัฒนาไม่ว่าจะเป็น SA/BA, Developer และ QA/Tester (และคนที่เกี่ยวข้อง) ต้องทำการตรวจสอบความถูกต้องเสมอนั่นคือการ Testing โดยที่ Developer ก็ต้องทำการทดสอบเช่นกัน เพื่อทำให้มั่นใจว่า code ที่เขียนขึ้นมานั้น ทำงานได้ตามที่คาดหวัง การเขียน code ก็เช่นกัน จำเป็นต้องมีการทดสอบด้วย การทดสอบ code ในแต่ละส่วน เราจะเรียกว่า Unit test สามารถทดสอบแบบ manual ได้นะ แต่ถ้า code มีจำนวนมากขึ้น จำนวน Unit test ก็มากขึ้นด้วย ดังนั้นการทดสอบแบบ manual ไม่น่าจะรอด
บางคนบอกว่า ทดสอบไปทำไม ไม่มีเวลา !! แต่บอกว่าพัฒนาเสร็จได้อย่างไร ?
ดังนั้นสิ่งที่ Developer ควรทำคือ การบันทึกกาทดสอบของ code ในส่วนต่าง ๆ ไว้ ในรูปแบบของ code ของการทดสอบ นั่นคือ Unit test โดย Unit test จะมีจำนวนมากขึ้นเรื่อย ๆ สามารถทำการทดสอบซ้ำได้บ่อยเท่าที่ต้องการ ทดสอบได้รวดเร็วขึ้น ลดเวลาในการทดสอบทั้งหมด หรือ regression testing และเพิ่มความมั่นใจมากขึ้น
แต่ถ้า Developer เข้าใจผิด !! แต่ถ้า Developer เข้าใจไม่ครบ !! แต่ถ้า Developer ไม่มีความรับผิดชอบ !! ถึงแม้ว่าจำนวนของ test coverage หรือ % ของ code ที่มี test ครอบคลุมเป็น 100% ก็ตาม Bug หรือข้อผิดพลาดก็เกิดขึ้นอยู่ดี

แต่สิ่งที่ทำให้เรารู้คือ ความผิดพลาด

เรียนรู้กับมัน ว่าเราผิดพลาดอะไร ? ว่าเราขาดตกบกพร่องอะไร ? เพื่อทำการแก้ไขและปรับปรุงให้ดียิ่งขึ้น จากนั้นเขียนชุดการทดสอบเช่น Unit test ขึ้นมา แน่นอนว่าผลการทำงานต้องไม่ผ่าน จากนั้นทำการแก้ไข code ซะ จนกว่าผลการทดสอบจะผ่าน สุดท้ายเราก็จะได้ ชุดการทดสอบที่ดีกว่าเดิม
ที่สำคัญเราจะไม่ผิดที่เดิม ( คนที่ผิดเรื่องเดิมซ้ำ ๆ ไม่น่าให้อภัยนะ )

สุดท้ายแล้วนั้น

การเขียนชุดการทดสอบนั้นต้องเป็นส่วนหนึ่งของ feature ที่พัฒนาเสมอ ไม่ว่าจะเป็น Unit/Integration/Acceptance test ไม่มีคำว่าเดี๋ยว หรือ ทำทีหลัง เพราะว่าสุดท้ายคุณก็ต้องทดสอบอยู่ดี ดังนั้นก่อนลงมือพัฒนาคิดให้เยอะ ๆ มิเช่นนั้นก็จะจมอยู่ในโคลนที่เราสร้างกันขึ้นมาเอง
คำถาม Bug คืออะไร ?
ขอให้สนุกกับการ coding ครับ
↧

ข้อมูลจาก StackOverflow บอกว่าภาษา Python ได้รับความนิยมอย่างมาก

September 25, 2017, 12:49 am
$
0
0

อ่าน blog จาก StackOverflow เรื่องแนวโน้มของภาษาโปรแกรม ที่ได้รับความนิยมจากประเทศที่มีรายได้ต่อหัวสูง ๆ หรือ World Bank High Income ผลที่ออกมาคือ ภาษา Python นั่นเอง โดยแสดงผลดังรูป

เมื่อดูแนวโน้มจาก StackOverflow Trend Insight จะพบว่า

ภาษา Python มีแนวโน้มที่สูงขึ้นมาอย่างต่อเนื่อง เมื่อเปรียบเทียบกับภาษาโปรแกรมอื่น ๆ ใน Top 10 แสดงดังรูป

ล่าสุดมีอีก blog ลงรายละเอียดว่าทำไมภาษา Python ถึงได้รับความนิยม

เนื่องจากมีการพัฒนาได้หลายอย่าง เช่น
  • Web development เช่น Django และ Flask
  • Data science และ Machine learning เช่น NumPy, matplotlib และ pandas
  • Ad-hocs task
เมื่อดูแนวโน้มก็พบว่า มีการใช้ package ต่าง ๆ ทาง Data science สูงมาก ๆ จะเห็นได้ว่า คำถามที่เกี่ยวกับ package pandas นั้น มีจำนวนถึง 1% จากทั้งหมดของ StackOverflow ซึ่งเยอะมาก ๆ แสดงให้เห็นว่าเรื่องเกี่ยวกับ Data science และ Machine learning ได้รับความนิยมสูงมาก ๆ นักพัฒนาไม่น่าพลาดนะครับ แสดงดังรูป

แต่เมื่อกลับไปดูข้อมูล Year over Year (YoY) ของแต่ละภาษาโปรแกรม

พบว่ามีหลาย ๆ ภาษาที่สูงขึ้นอย่างมาก ซึ่งไม่ถูกพูดมากนัก เนื่องจากเป็นส่วนเล็ก ๆ ดังนั้นผมจึงลองไปดูแนวโน้มกันหน่อย คัดเฉพาะที่มีความนิยมขึ้นสูงมาก ๆ ยกตัวอย่างเช่น
  • Kotlin
  • R
  • TensorFlow
  • Go
  • Scala

ภาษา Kotlin ได้รับความนิยมสูงขึ้นแบบสุด ๆ

จากการเปิดตัวอย่างเป็นทางการสำหรับภาษาที่ใช้พัฒนา Android app จากงาน Google I/O 2017 นั่นเอง

ภาษา R โตขึ้นอย่างต่อเนื่องตามงาน Data science นั่นเอง

TensorFlow ก็พุ่งแรงมาก ๆ ในงานสาย Machine Learning

ปิดท้ายด้วยเรื่องของ JavaScript framework คือ Reactjs vs Vuejs vs Angular

โดยจะพบว่าถ้าดูเพียง JavaScript มันไม่ได้บอกอะไรเลย แต่เมื่อลงรายละเอียดแต่ละตัว จึงเห็นชัดมาก ๆ ว่า ได้รับความนิยมสูงมาก ๆ แสดงดังรูป น่าจะเป็นประโยชน์สำหรับนักพัฒนาบ้างนะครับ Reference Websites https://stackoverflow.blog/2017/09/14/python-growing-quickly https://stackoverflow.blog/2017/09/06/incredible-growth-python/ https://stackoverflow.blog/2017/08/29/tale-two-industries-programming-languages-differ-wealthy-developing-countries/
↧

คำสั่ง Docker เบื้องต้นสำหรับ Java Developer

September 25, 2017, 7:21 pm
$
0
0

การนำ Docker มาใช้ในการพัฒนา software นั้นถือว่าเป็นสิ่งที่น่าสนใจมาก ๆ บางคนอาจจะบอกว่า น่าจะเป็นความรู้พื้นฐานของนักพัฒนาเลยนะ แต่ว่าการศึกษาสิ่งใหม่ ๆ ก็ไม่ใช่เรื่องที่ง่ายเลย ดังนั้นจึงสรุปขั้นตอนการใช้งาน Docker เป็น comand line นะ พร้อมยกตัวอย่างการใช้งานสำหรับการพัฒนาระบบด้วยภาษา Java

แนะนำการใช้งาน Docker แบบพื้นฐาน

Docker นั้นพัฒนาไปเร็วมาก ทำให้มี ecosystem ขนาดใหญ่ แต่การศึกษาทั้งหมดเป็นเรื่องที่ไม่ง่าย และ ใช้เวลานานมาก ดังนั้นใน blog นี้จะเน้นเรื่อง การใช้งาน Docker command line โดยเน้นไปที่การใช้งาน command line ชุดใหม่ ซึ่งมีการปรับเปลี่ยนให้เป็นหมวดหมู่และง่ายต่อการจำมากขึ้น ผลที่ตามมาคือ พิมพ์เยอะมากขึ้น ใน blog นี้จะแบ่งชุดคำสั่งเป็นกลุ่ม ๆ มาเริ่มกันเลย

1. การจัดการ image

Image คือต้นฉบับสำหรับการสร้าง container ต่าง ๆ โดยที่เราสามารถทำการจัดการได้ดังนี้ เลือกคำสั่งที่ใช้บ่อย ๆ
  • สร้าง image ใหม่ขึ้นมา กำหนดขั้นตอนการสร้างจาก Dockerfile
  • ทำการลบ image
  • ทำการดึง หรือ pull image มาจาก repository เช่น Docker Hub มายังเครื่องเราได้
  • ทำการ push image ไปยัง repository
เริ่มต้นจากการเลือก image จาก Docker Hub หรือจาก Official ของสิ่งที่เราต้องการ ยกตัวอย่างเช่น Java ก็มีให้เลือกทั้ง OpenJDK และ Oracle Java อีกทั้งยังมีจาก community อีกนะ เลือกได้ตามรสนิยมกันไปเลย ทั้ง OS เช่น Ubuntu, Alpine เป็นต้น โดยเราจะเรียกว่า Base Image นั่นเอง แสดงดังรูป เมื่อได้ image ที่ต้องการแล้ว ก็นำมาใช้ได้เลย สามารถทำการ download image ลงมาด้วยคำสั่ง [code] $docker image pull <ชื่อ image>:<ชื่อ tag> [/code] ยกตัวอย่างเช่นการใช้งาน image openjdk ซึ่งมีให้เลือกมากมายทั้ง OS, JDK และ JRE เราจะใช้งาน openjdk ด้วย tag 9-jdk ดังนี้ [code] $docker image pull openjdk:9-jdk [/code] จากนั้นทำการดูว่า image ถูก download มายังเครื่องของเราหรือไม่ ด้วยคำสั่ง [code] $docker image ls [/code] ถ้าต้องการลบ image ให้ใช้คำสั่ง [code] $docker image rm <ชื่อ image> [/code] หรือถ้าต้องการลบ image ที่ไม่ถูกใช้งานเลย สามารถใช้คำสั่งใหม่คือ prune ดังนี้ [code] $docker image prune [/code]
นี่แค่เริ่มต้นคำสั่งจัดการ image เบื้องต้นเท่านั้น แต่เพียงพอสำหรับผู้เริ่มต้น

เมื่อได้ image หรือ base image ที่ต้องการแล้ว

ถ้าเราไม่พอใจ สามารถทำการแก้ไขและสร้าง image ใหม่ขึ้นมา เพื่อให้เหมาะสมกับระบบที่เราต้องการได้ สามารถกำหนดขั้นตอนการสร้าง image ผ่านไฟล์ Dockerfile ตัวอย่างง่าย ๆ ต้องการสร้าง image สำหรับการ compile และ run โปรแกรมที่พัฒนาด้วยภาษา Java คือ javac และ java มีขั้นตอนดังนี้
  • เลือก Base image ซึ่งจะใช้ openjdk:9-jdk
  • ทำการสร้าง working directory สำหรับจัดเก็บ source code
  • กำหนด endpoint ให้ทำการ run bash shell ขึ้นมา
[gist id="07d5005207469bbe9c7d8da7ca5dd712" file="HelloDockerfile"] สร้าง image จาก Dockerfile ด้วยคำสั่ง [code] $docker image build -t <ชื่อ image>:<ชื่อ tag> . [/code] จากตัวอย่างถ้าต้องการสร้าง image ชื่อว่า hello_java ทำได้ดังนี้ [code] $docker image build -t hello_java . [/code] ส่วนการใช้งานต้องสร้าง container ขึ้นมาจาก image นี้ต่อไป ยกตัวอย่างเช่น [code] $docker container run --name java_compile -v $(pwd)/src:/my_project —rm hello_java javac Hello.java $docker container run --name java_run -v $(pwd)/src:/my_project —rm hello_java java Hello [/code]
ชีวิตน่าจะดีขึ้น ลองคิดดูสิว่า ถ้าเราต้องการ run java มากกว่า 1 version เราจะต้องทำอย่างไร ?
ตัวอย่างที่ซับซ้อนขึ้น ต้องการสร้าง image สำหรับระบบงานที่พัฒนาด้วยภาษา Java และต้องทำการ compile และ build ด้วย Apache Maven ดังนั้นเราต้องกำหนดขั้นตอนการสร้าง image ของเราดังนี้
  • เลือก Base image ซึ่งจะใช้ openjdk:9-jdk
  • ทำการติดตั้ง package ต่าง ๆ ที่จำเป็นนั่นคือ Apache Maven และ Vim เอาไว้แก้ไข code
  • ทำการสร้าง working directory สำหรับจัดเก็บ source code
  • กำหนด endpoint ให้ทำการ run bash shell ขึ้นมา
สามารถเขียนใน Dockerfile ได้ดังนี้ [gist id="07d5005207469bbe9c7d8da7ca5dd712" file="Dockerfile"] ทำการสร้าง image ชื่อว่า my_image ใหม่จาก Dockerfile ด้วยคำสั่ง [code] $docker image build -t my_image . [/code] โดยการสร้าง image จะใช้เวลานานนิดหน่อย ถ้าไม่ใสชื่อ tag เข้าไปจะมีค่า default เป็น latest นะ เพียงเท่านี้เราก็ได้ image ใหม่มาใช้งานกันแล้ว ในแต่ละบรรทัดของ Dockerfile นั่นหมายถึงจำนวน layer หรือชั้นของ image เราด้วย สามารถดูได้ว่าแต่ละ image มี layer อะไรบ้างด้วยคำสั่ง [code] $docker image history <ชื่อ image>:<ชื่อ tag> [/code] เมื่อเราได้ image ที่ต้องการแล้ว สามารถนำ image นี้ไปเก็บยัง repository ของ Docker ได้ ไม่ว่าจะเป็น Docker hub หรือ registry ของเราเอง ด้วยคำสั่ง [code] $docker image push <ชื่อ image>:<ชื่อ tag> [/code] มาถึงตรงนี้น่าจะพอทำให้เข้าใจเกี่ยวกับการจัดการ image ขั้นพื้นฐานบ้างแล้ว แน่นอนว่ายังมีอีกเยอะนะ แต่อยากขอแนะนำเพิ่มเติมเพื่อให้ศึกษาต่อคือ

2. การจัดการ container

หลังจากที่ได้ image ที่ต้องการแล้ว สิ่งต่อมาที่จะต้องทำคือ การสร้าง container จาก image เหล่านั้น เทียบง่าย ๆ คือ การสร้าง instance/object จาก class ใน OOP นั่นเอง โดยทาง docker ได้เตรียม command line สำหรับการจัดการ container มาให้เพียบ แต่เรามาใช้งานคำสั่งที่ใช้บ่อย ๆ กัน เริ่มด้วยการสร้าง container จาก image [code] $docker container run<options> <ชื่อ image> <command> <arguments> [/code] จะเห็นได้ว่ามีให้ใส่ option ซึ่งมีเยอะมาก ๆ ดังนั้นมาดูตัวอย่างกัน ใช้ image จากข้างต้น
  • สร้าง container ชื่อ demo01
  • สร้างจาก image ชื่อว่า my_image
  • map path จากเครื่องของเราหรือเรียกว่า host ไปยัง container
  • Run container แบบ foreground mode (แสดงว่ายังมี mode อื่นอีกเช่น interactive และ background เป็นต้น)
  • ลบ container ทิ้งทันทีหลังจากทำงานเสร็จสิ้น
  • Run คำสั่งของ Apache Maven เพื่อ compile และ build ระบบงาน
สร้าง container ด้วยคำสั่ง [code] $docker container run --name demo01 -v $(pwd)/src:/my_project --rm my_image mvn clean package [/code] เพียงเท่านี้ก็สร้าง container ได้แล้ว และทำงานตาม command ของ Apache Maven ที่ต้องการ run มันง่ายและสะดวกมาก ๆ สำหรับนักพัฒนา ลองคิดดูว่า ถ้าทุกคนในทีมพัฒนาใช้งาน image เดียวกัน ถ้าทุกคนในทีมพัฒนาทำการสร้าง container เหมือนกัน นั่นคือทุกคนมีขั้นตอนการทำงานเหมือนกัน ที่สำคัญถ้า image นี้เหมือนกับสิ่งที่จะ deploy บน production server ก็น่าจะลดปัญหาต่าง ๆ ได้มากมาย จริงไหม ? ถ้าต้องการดูว่ามี container อะไรบ้างก็ใช้คำสั่ง ตัวอย่างดู container ทั้งหมด ทุกสถานะ [code] $docker container ls -a [/code] ยังมีคำสั่งอื่น ๆ ที่ใช้จัดการ container ทั้ง stop/start/restart/rm [code] $docker container stop <ชื่อ container> $docker container start <ชื่อ container> $docker container restart <ชื่อ container> $docker container rm <ชื่อ container> [/code] ถ้าต้องการลบ container ที่ไม่ทำงานสามารถใช้คำสั่ง prune ได้ [code] $docker container prune [/code] ถ้าต้องการลบ container ทั้งหมด ทุกสถานะ สามารถใช้คำสั่งนี้ได้เลย ใช้บ่อย [code] $docker container stop $(docker container ls -a -q) $docker container rm $(docker container ls -a -q) [/code] ยังไม่พอนะ ยังมีชุดคำสั่งสำหรับดู stat/log การทำงานของแต่ละ container ได้อีกด้วย [code] $docker container stats <ชื่อ container> $docker container top <ชื่อ container> $docker container logs <ชื่อ container> [/code] เพียงเท่านี้ก็น่าจะเพียงพอสำหรับการเริ่มต้นจัดการ container นะ

3. การกำหนดจำนวน resource ต่าง ๆ ทั้ง CPU และ Memory ให้ container

[code] $docker container update<options> container [/code] สำหรับชาว Java นั้นเรื่องนี้สำคัญมาก ๆ เนื่องจากถ้ากำหนดไม่ดี และไม่เข้าใจการทำงานของ JVM แล้ว ก็อาจเกิดข้อผิดพลาดได้ ยกตัวอย่างเช่นการใช้ resource เกินจำนวนที่กำหนด สามารถดูปัญหาและการแก้ไขได้จาก JVM is Docker-aware

คำสั่งสุดท้ายคือ การลบข้อมูลที่ไม่ใช้งานทิ้งไป

ลบทั้ง image, container, volume และ network รวมไปถึง layer ของจากการสร้าง image อีกด้วย ซึ่งทำให้เราได้พื้นที่ disk กลับคืนมาอย่างมากมาย [code] $docker system prune<options> [/code] แต่คำสั่งนี้ไม่ลบพวก container volume นะ ถ้าอยากจะลบต้องเพิ่ม option -volume เข้าไปด้วย
เพียงเท่านี้น่าจะพอมีประโยชน์สำหรับผู้เริ่มต้นบ้างนะครับ เริ่มต้นด้วย container เดียวก่อน น่าจะทำให้มีกำลังใจมากยิ่งขึ้น จากนั้นก็นับสองสามสี่ต่อไปครับ
ยกตัวอย่างเรื่องที่ต้องศึกษาต่อเช่น
ถามว่าชุดคำสั่งเยอะไหม ? ตอบเลยว่ามาก ถามว่าต้องจำหมดไหม ? ตอบเลยว่าไม่ ดังนั้นสิ่งที่สำคัญสุด ๆ ความเข้าใจ และ keyword ที่ต้องการ
ขอให้สนุกกับการ coding ครับ
↧

ว่าด้วยเรื่อง Twelve Factor App กับกับการพัฒนาระบบงาน

September 26, 2017, 4:42 am
$
0
0

สิ่งที่นักพัฒนาน่าจะต้องรู้สำหรับการพัฒนาระบบงานในปัจจุบัน นั่นก็คือ The Twelve Factor App ซึ่งเป็นคำแนะนำสำหรับการพัฒนาระบบที่ดี โดยเฉพาะ Cloud Native App มีเป้าหมายเพื่อ
  • Portability ระหว่าง environment ต่าง ๆ
  • Scale ได้ง่ายทั้งขยายและลด
  • ลดค่าใช้จ่ายและเวลาด้วยการทำงานแบบอัตโนมัติ
  • Continuous Deployment
สามารถนำมาปรับใช้กับระบบอื่น ๆ ได้ ดังนั้นมาดูกันดีกว่า ว่ามีอะไรบ้าง ?

Factor 1 : Codebase

One codebase tracked in revision control, many deploys นั่นคือ codebase ของระบบ ต้องถูกจัดการ version ใน Version Control System (VCS) โดยที่ 1 codebase อาจจะหมายถึง 1 ระบบ หรือ service/process ก็ได้ หัวใจของข้อนี้คือ การจัดการ version ของ source code และสามารถ deploy ได้ตลอดเวลา ในทุก ๆ environment

Factor 2 : Dependencies

Explicit declare and isolate dependencies เป้าหมายของข้อนี้คือ การแยก dependency ต่าง ๆ ออกมาจากระบบงาน เพื่อลดปัญหาเรื่องของ dependency hell ทำให้สามารถ deploy ระบบงานได้บ่อยและง่ายขึ้น โดยที่การแยก dependency ออกมามีหลายแบบเช่น Developer ทำการกำหนดไว้ในการ build process ของการพัฒนา Platform ทำการกำหนดไว้ที่ platform ที่จะ deploy เลย ยกตัวอย่างของ Spring boot ปกติจะ embedded runtime ให้เลย แต่เราก็สามารถเอาออกไปได้เช่นกัน ถ้า runtime นั้นถูกเตรียมจาก platform ที่จะติดตั้ง

Factor 3 : Config

Store the config in the environment ก่อนอื่นมาดูก่อนว่า configuration มีอะไรบ้าง ?
  • ข้อมูลการใช้งาน database และ service ต่าง ๆ
  • พวก credential สำหรับการติดต่อไปยังระบบข้างนอก
  • สิ่งที่ต้องกำหนดสำหรับการ deploy ในแต่ละ environment
  • อะไรก็ตามที่ต้องเปลี่ยนแปลงในแต่ละ environment เช่น dev, test, staging และ production เป็นต้น
ที่สำคัญระบบงานของเราต้องไม่เก็บ configuration ต่าง ๆ ไว้ใน
  • Code
  • Properties file
  • Build process
  • Application/Web server
ดังนั้นจึงแนะนำให้เก็บไว้ใน Environment variable ของเครื่องที่จะ deploy ไปเลย หรือในระบบ cloud สามารถจัดเก็บไว้บน Cloud configuration ก็ได้ (Centralize configuration) ยกตัวอย่างการใช้งานใน Spring Boot app [gist id="4933c208c33de85a813fa9910858df72" file="Application.java"]

Factor 4 : Backing service

Treat backing services as Attached resources Service ต่าง ๆ ต้องสามารถเข้าถึงได้ง่าย เช่นด้วยชื่อ ด้วย url ที่สำคัญต้องสามารถ้แลี่ยนแปลงได้ง่ายอีกด้วย แน่นอนว่าต้องทำงานร่วมกับ Factor 3 : Config ด้วย ยกตัวอย่างเช่นการใช้งาน docker compose [gist id="4933c208c33de85a813fa9910858df72" file="docker-compose.yml"] ทำให้แต่ละ service อ้างอิงกันด้วยชื่อในทุก ๆ environment ซึ่งส่งผลดีต่อทุกฝ่าย ที่สำคัญไม่ต้องมาแก้ไข configuration กับทุก ๆ environment

Factor 5 : Design, Build, Release, Run

Strictly separate stages ปกติจะแยกเป็น stage ดังนี้
  • Design/Develop นักพัฒนาจะเป็นคนทำในส่วนนี้ ว่าใช้เครื่องมืออะไรบ้าง มี dependency อะไรบ้าง
  • Build ในส่วนนี้จะเป็นหน้าที่ของ Continuous Integration Server ทำการ build/compile/package โดยผลที่ได้เช่นไฟล์ EAR/WAR/JAR ซึ่งสามารถนำไป deploy ต่อไป
  • Release เป็นขั้นตอนในการ release เช่นการสร้าง image เพื่อใช้ในการสร้าง container ต่อไป
  • Run เป็นขั้นตอนในการ run หรือสร้าง container จาก image ที่ต้องการ ซึ่งมีความเร็วสูงมาก ๆ
เมื่อเราแยก stage ออกมาได้แล้ว เราต้องออกแบบ pipeline ของการทำงานในรูปแบบอัตโนมัติ เพื่อให้ได้รับ feedback ได้อย่าวรวดเร็วเมื่อมีการเปลี่ยนแปลง ซึ่งเราเรียก pipeline นี้ว่า Deployment pipeline ยกตัวอย่างเช่น
  1. Commit code/test
  2. Run unit test
  3. Run integration test
  4. Create and keep deployable artifact
  5. Deploy to Dev environment
  6. Run UI/Acceptance test
  7. Deploy to Test environment
  8. Deploy to Production environment

Factor 6 : Processes

Execute the app as one or more stateless processes นี่คือแนวคิดของ Microservice คือ Design for Failure เราไม่กลัวว่าระบบจะ failure เนื่องจากความเร็วของการ deploy ของ app เร็วเหมือนกับ process ที่สำคัญมีการทำงานแบบ stateless ทำให้สามารถ scale ได้ง่ายขึ้น และเมื่อเกิดปัญหาขึ้นมาก็สามารถเอาของเก่ากลับคืนมาได้อย่างรวดเร็ว ซึ่งเรื่องนี้คือ ความเจ็บปวดของการ deploy ระบบ !!

Factor 7 : Port Binding

Export services via port bindings นี่คือแนวคิดของ containerization เลย นั่นคือระบบงานทำการ deploy ในรูปแบบ container โดยในแต่ละเครื่องสามารถมีได้มากกว่า 1 container จากนั้นเครื่องหลักหรือ host ของเราต้องสามารถจัดการเรื่อง port binding ได้ ซึ่งอาจจะต้องมี service มาช่วยเช่น load balance/routing เป็นต้น

Factor 8 : Concurrency

Scale out via the process model จากข้อ 6 และ 7 นั้นช่วยทำให้เราสามารถ scale ระบบได้ง่ายขึ้น และทำการ scale เฉพาะส่วนที่ต้องการได้ เช่น frontend, backend, database และ queue เป็นต้น

Factor 9 : Disposability

Maximize robustness with fast startup and graceful shutdown สิ่งที่น่าสนใจคือ เราไม่สามารถทำการ scale, deploy, release และ recovery ได้เร็ว ถ้าไม่สามารถ start service หรือระบบได้อย่างรวดเร็ว อีกเรื่องของการ shutdown มันต้องคืน resource ต่าง ๆ ก่อน shutdown เสมอ มิเช่นนั้นจะไม่สามารถ start ใหม่ได้เลย เช่น connection ของ database ? มี job รอทำงานหรือกำลังทำงานของ service/process นั้นหรือไม่ ? ไม่เช่นนั้นระบบพังแน่นอน !!

Factor 10 : Dev/Prod parity

Keep development, staging and production as similar as possible เมื่ออ่านข้อนี้แล้ว อาจจะบอกว่าเราทำไม่ได้หรอกนะ !! ด้วยเหตุผลร้อยแปด แต่ถ้าทำได้ มันจะช่วยลดปัญหาต่าง ๆ ไปมากมาย ที่สำคัญ Twelve Factor App นั้นออกแบบมาเพื่อ Continuous Deployment ดังนั้นถ้า environment ต่าง ๆ ไม่เหมือนกันแล้ว ก็อาจจะทำให้การ deploy พังบ่อยก็ได้ หรือเกิดปัญหาที่ไม่สามารถคาดเดาได้เลย ดังนั้นแต่ละ environment ควรเหมือนกันให้มากที่สุด เนื่องจากมันควรเหมือนกันเท่านั้นเอง ถ้าไม่เหมือน ก็ทำให้เหมือน แค่นั่นเอง

Factor 11 : Logs

Treat logs as Event streams เราคงต้องเก็บ log ของระบบตามแต่ละระบบไป โดยที่ Log นั้นต้องการสามารถเปลี่ยน configuration ได้ง่ายตาม Factor ที่ 3

Factor 12 : Admin processes

Run admin/management processes as one-off processes มี process สำหรับการจัดการการ release ต่าง ๆ จะมีชุดคำสั่งหรือ command ต่าง ๆ ให้ใช้งาน สามารถใช้งานได้ในทุก ๆ environment เช่น
  • Database migration
  • REPL shell (Read Eval Print Loop) สำหรับการ run code บน environment
  • ทำการ run คำสั่ง adhocs ต่าง ๆ เช่น fix bug และแก้ไขข้อมูล

ยังมีเพิ่มเติมจาก 12 ข้อข้างต้นอีกนะ ประกอบไปด้วย

  • การ Audit
  • การ Authentication และ Authorization
  • API-first

สุดท้ายและท้ายสุด

ลองกลับมาดูระบบงานของเราสิว่า เมื่อมาตรวจสอบด้วย Twelve Factor App แล้วเป็นอย่างไรบ้าง ? ขอให้สนุกกับการ coding ครับ Reference Websites https://www.infoq.com/presentations/12factor-spring https://dzone.com/articles/the-12-factor-app-a-java-developers-perspective
↧
↧

สวัสดี React 16

September 27, 2017, 1:28 am
$
0
0

เห็นข่าว React 16 ออกมาแล้ว สิ่งที่น่าสนใจมาก ๆ คือ การทำงานของ React เปลี่ยนไปใช้ Fiber นั่นคือการ rewrite core algorithm ของ React นั่นเอง โดยที่ Fiber นั้นจะช่วยปรับปรุงประสิทธิภาพและเพิ่ม feature ใหม่ ๆ ที่เกี่ยวกับ animation, layout และ gesture รวมทั้ง incremental rendering

สิ่งแรกที่สำคัญมาก ๆ ต่อการเปลี่ยนแปลงคือ

ชุดการทดสอบของ React ซึ่งเขียนด้วย Jest สำหรับทดสอบ feature ต่าง ๆ ทั้งหมด แน่นอนว่ามันต้องผ่านทั้งหมดดังรูป

เขียน Core Algorithm ของ React ใหม่ด้วย Fiber

โดย feature หลัก ๆ คือ asynchronous rendering (แต่ไม่มีใน) นั่นคือการส่วนการทำงานเล็ก ๆ แยกการทำงานออกไปหลาย ๆ frame จากเดิมที่ทำการแบบ single thread หรือทำงานแบบ synchronous แต่ของใหม่จะไม่ทำการ block main thread อีกต่อไป แต่ใน release แรกนี้จะปิด feature นี้ก่อนนะ เนื่องจากจะเน้นไปที่การ migrate ก่อน ดังนั้นต้องรอใน release ถัดไปครับ การ render ข้อมูลใน React 16 ใช้ลำดับความสำคัญเป็นหลัก นั่นคือ ถ้ามีการเปลี่ยนแปลงหรือเกิดเหตุการณ์ตรงไหน จะทำการ update ในส่วนนั้นก่อนเสมอ ทำให้ผู้ใช้งานเห็นการเปลี่ยนแปลงทันที ดังนั้นการเรียก method ใน Component Lifecycle ทั้ง componentWillUpdate, shouldComponentUpdate ก็อาจจะมีปัญหา โดยมีคนลองทำ performance test สำหรับการ render แล้ว พบว่าเวลาใน render ลดจาก 50 milliseconds เหลือเพียง 15 millisecond เท่านั้น ขนาดของ React 16 ก็เล็กลงจาก 15.6.1 ประมาณ 30% ซึ่ง React เองใช้ Rollup ในการ compile code

ใครที่ว่าง ๆ ลองไปค้นหาคำว่า useFiber ใน Github : React ดู

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

ส่วน feature หลักที่น่าสนใจ ประกอบไปด้วย

  • มี Error boundary มาแก้ไขปัญหาถ้าเกิด error ขึ้นมาแล้ว app ไม่ควรพังทั้งหมด
  • การจัดการเกี่ยวกับ error จะมี component stack trace ให้ ทำให้การ debug ง่ายขึ้น
  • สามารถ return ข้อมูลชนิด string จาก method render() ได้
  • สามารถ return ข้อมูลชนิด array ของ element จาก method render() ได้ แต่ต้องใส่ attribute ชื่อว่า key ด้วยนะ
  • Server side render ที่เร็วขึ้น
ตัวอย่างการใช้งาน Error boundary ตัวอย่างการ return array ของ element [gist id="9561a49817893e39416a84600f24195a" file="key.js"]

สุดท้ายจะรออะไรครับ ติดตั้งเลย

[code] $yarn add react@^16.0.0 react-dom@^16.0.0 หรือ $npm install --save react@^16.0.0 react-dom@^16.0.0 [/code]

ส่วนถ้าใครใช้ Create React App สร้าง project ใหม่

ก็จะได้ React 16 มาใช้งานอยู่แล้ว ยังไม่พอนะ React Native Web ก็ยังสนับสนุน React 16 อีกด้วย ส่วนเรื่องของ license ที่ drama กัน ตอนนี้ทั้ง React, Jest, Flow และ Immutable.js เปลี่ยนเป็น MIT license แล้วนะ ขอให้สนุกกับการ coding ครับ
↧

[Python] เตรียมข้อมูลให้พร้อมสำหรับการวิเคราะห์ ด้วย Pandas library กัน

September 29, 2017, 12:18 am
$
0
0

ระหว่างนั่งรอเครื่องบินไปจังหวัดเชียงใหม่ เจอข้อมูลที่น่าสนใจจาก sensor เกี่ยวกับสภาวะอากาศ จึงนำมาใช้ฝึกการ cleaning ข้อมูลด้วย Pandas library กันหน่อย โดยขั้นตอนการทำงานประกอบไปด้วย
  1. อ่านข้อมูลจากไฟล์ CSV
  2. ทำการจัดเรียงข้อมูล
  3. ทำการ transform ข้อมูลในแต่ละ column
  4. ทำการจัดการเรื่อง missing value
  5. การ plotting หรือแสดงข้อมูลในรูปแบบ graph
มาเริ่มกันหน่อย

การอ่านข้อมูลจากไฟล์ CSV

ใน pandas นั้นจะมี function การอ่านข้อมูลจากไฟล์ CSV ให้ ดังนี้ [gist id="b055f158ce622d0a1d2d145523774309" file="1.py"] ผลที่ออกมามันก็อ่านได้นะ แต่ไม่เป็นไปตามที่ต้องการ ทำไมมันมีเพียง 1 column ละ ? จะเห็นได้ว่าข้อมูลในแต่ละ column แบ่งด้วย tab (\t) ดังนั้นต้องใส่ parameter เพื่อกำหนดตัวแยกหรือ separator เป็น tab (\t) เพิ่มเติมใน function read_csv() นั่นเอง ดังนี้ [gist id="b055f158ce622d0a1d2d145523774309" file="2.py"] ผลที่ได้เป็นดังนี้ ซึ่งจะแยกข้อมูลออกเป็น column ตามที่ต้องการ จากข้อมูลจะพบว่า มีข้อมูลบางตัวเป็นค่า (-) หรือไม่มีข้อมูลนั่นเอง ดังนั้นสิ่งที่ต้องคิดและวิเคราะห์คือ จะเปลี่ยนเป็นอะไร เช่น NaN (Not a Number) เป็นต้น แน่นอนว่า เราสามารถกำหนดใน function read_csv() ได้ ดังนี้ [gist id="b055f158ce622d0a1d2d145523774309" file="2.py"] ได้ผลการทำงานดังนี้ มาถึงตรงนี้ สิ่งที่แปลก ๆ หน่อยคือ column Date และ Time แยกกัน !! คำถามที่เกิดขึ้นมาคือ มีการใช้งานข้อมูล Date และ Time หรือไม่ ? และใช้อย่างไร ? ถ้าบอกว่าต้องใช้งาน และ จำเป็นต้องรวมทั้งสองให้เป็น column เดียวคือ DateTime ก็สามารถทำใน function read_csv() ได้เช่นกัน
  • parse_dates กำหนดว่า column ไหนบ้างที่จะเป็น date โดยกำหนดให้รวมเป็น column เดียว
  • dayfirst กำหนดให้รูปแบบของข้อมูลให้วันที่อยู่หน้าเดือน เช่น
  • infer_datetime_format กำหนดให้ Pandas library เดา format ของ date เอง
ดังนี้ [gist id="b055f158ce622d0a1d2d145523774309" file="4.py"] ได้ผลการทำงานดังนี้ ทำการเรียงข้อมูลกันหน่อย เนื่องจากข้อมูลของ sensor นั้น จะอยู่ในรูปแบบของ Time-serie ดังนั้นสิ่งที่เราต้องทำคือ เรียงข้อมูลด้วย Datetime (index) ซึ่งสามารถเขียน code ได้ดังนี้ [gist id="b055f158ce622d0a1d2d145523774309" file="5.py"] แสดงผลการทำงานดังนี้ เมื่อลองสังเกตุจะเห็นว่าข้อมูล Datetime มีซ้ำด้วย !! ทำการตรวจสอบในทุก ๆ วันพบว่ามีเวลาซ้ำกันคือ 00:00:00 (เที่ยงคืน) เป็นข้อมูลของการเริ่มวันและสิ้นวัน ดังนั้นทำการแก้ไขข้อมูลที่ซ้ำกันก่อน โดยสามารถเลือกได้ว่าจะเก็บข้อมูลแรกหรือสุดท้าย [gist id="b055f158ce622d0a1d2d145523774309" file="6.py"] ได้ผลการทำงานดังนี้ มาถึงตรงนี้น่าจะเรียงข้อมูลได้ดีพอประมาณ

ทำการแปลงข้อมูลให้อยู่ในรูปแบบที่ประมวลผลได้ (Transform)

ปัญหาของข้อมูลส่วนใหญ่คือ ข้อมูลที่จัดเก็บไม่สามารถนำมาประมวลผลได้ ตัวอย่างจากข้อมูลชุดนี้คือ column Wind dir (Wind direction) หรือทิศทางของลม
  • ENE ?
  • SSW ?
  • SW ?
ค่าที่เป็นไปได้ของ Wind direction มีกี่ค่า ? ดังนั้นมาดูหน่อยสิว่ามีค่าอะไรบ้าง [gist id="b055f158ce622d0a1d2d145523774309" file="7.py"] คำถามต่อมาคือ ค่าที่เป็นไปได้มีทั้งหมด 16 ค่า แล้วแต่ละตัวมันคืออะไร ? เราจะทำการแปลงอย่างไร ? เราจะทำการแปลงไปเป็นค่าตัวเลขอะไร ?
ปล. อย่าลืมว่า เราต้องมีความรู้ความเข้าใจกับข้อมูลด้วยเสมอ หรือถ้าไม่มีต้องมีผู้เชี่ยวชาญให้คำปรึกษาด้วยเสมอ
จากตัวอย่างทำการกำหนด Wind direction แต่ละตัวด้วยองศา จากนั้นทำการเรียกใช้ method apply() ในแต่ละ column ดังนี้ [gist id="b055f158ce622d0a1d2d145523774309" file="8.py"] ได้ผลการทำงานดังนี้

เมื่อทำการทำความสะอาดข้อมูลได้เป็นที่น่าพอใจแล้ว

ก็ลองทำการแสดงในรูปแบบกราฟหน่อยสิ ด้วย library ที่ใคร ๆ ก็ใช้คือ matplotlib เพื่อแสดงข้อมูลจาก column ต่าง ๆ โดยใช้ข้อมูล 500 row แรกก็พอ เพื่อดูว่าข้อมูลมีปัญหาอะไรหรือไม่ ? [gist id="b055f158ce622d0a1d2d145523774309" file="9.py"] ผลการทำงานเป็นดังนี้ ถ้าสังเกตุดี ๆ จะเห็นว่ามีข้อมูลในบางช่วงไม่มี !! ทำให้เส้นในกราฟมันขาด ๆ หาย ๆ เป็นช่วง ๆ แสดงดังรูป ดังนั้นสิ่งที่เราต้องทำคือ เพิ่มข้อมูลใหม่เข้ามา เพื่อทำให้กราฟเส้นไม่ขาด โดยใน pandas library นั้นจะมี Series.interpolate() ให้ใช้งาน [gist id="b055f158ce622d0a1d2d145523774309" file="10.py"] ผลที่ได้จะเป็นดังรูป

มาถึงตรงนี้น่าจะพอทำให้เห็นว่า

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

ยังมีเรื่องอื่น ๆ อีก เช่น

  • การตรวจสอบ missing data
  • การจัดการข้อมูล missing data
  • การ cleaning ข้อมูล
  • การกรองข้อมูล
  • การจัดกลุ่ม
ลองศึกษาเพิ่มเติมกันได้ ขอให้สนุกกับการ coding ครับ
ปล. ที่ทำมานั้นสามารถทำได้ใน Spreadsheet program ได้หมดนะ แต่ถ้าข้อมูลมันเยอะ ๆ แล้ว Pandas library จะเหมาะมาก ๆ
Reference Websites https://opensource.com/article/17/9/messy-sensor-data https://www.oreilly.com/learning/handling-missing-data https://chrisalbon.com/python/pandas_missing_data.html
↧
Search

บันทึกการติดตั้ง Continuous Integration Server ด้วย Jenkins ใน Give&Take ที่เชียงใหม่

October 1, 2017, 6:11 am
$
0
0

ตั้งแต่วันที่ 29 กันยายน ถึง 1 ตุลาคม มีโอกาศมาแบ่งปันที่เชียงใหม่ ในงาน Give and Take :: Agile for Software Development ซึ่งครั้งที่จัดที่ CAMT (College of Arts, Media and Technology ) โดยครั้งนี้ทำการติดตั้งและ configuration ระบบ Continuous Integration Server ด้วย Jenkins ไว้ เลยนำมาสรุปไว้นิดหน่อย

เริ่มจาก Infrastructure ที่ใช้คือ Digital Ocean

ซึ่งใช้เพียง 1 instance หรือ 1 droplet เท่านั้น โดยสิ่งที่นำมาใช้เพิ่มเติมคือ Docker สำหรับการสร้าง container ของส่วนต่าง ๆ ในระบบงาน ประกอบไปด้วย
  • Container Jenkins Server
  • Container Nginx สำหรับ deploy ระบบ web application ที่พัฒนาด้วย React
  • Container NodeJS สำหรับ deploy ระบบ backend ที่พัฒนาด้วย NodeJS
  • Container MongoDB สำหรับ database ของระบบ
  • Container Google Chrome สำหรับการทดสอบ UI testing บน Google Chrome
มาดูการสร้าง Container Jenkins Server จะใช้ image Jenkins LTS ทำการสร้างด้วยคำสั่ง [code] $docker container run -d -p 8080:8080 --name ci jenkins/jenkins:lts จากนั้นทำการดึงค่า Admin Password มาใช้ในขั้นตอนติดตั้ง $docker container exec -it ci cat /var/jenkins_home/secrets/initialAdminPassword [/code] เพียงเท่านี้ก็ได้ Jenkins Server มาใช้แบบง่าย ๆ แล้ว ต่อจากนี้ยากหมดเลย !!

ทำการสร้าง Job หรือขั้นตอนการทำงานแบบอัตโนมัติง่าย ๆ ดังนี้

1. Frontend ที่พัฒนาด้วย React 2. Backend ที่พัฒนาด้วย NodeJS 3. ทำการสร้าง MongoDB Database ขึ้นมาใหม่ 4. ทำการทดสอบ UI Test ผ่าน Google Chrome ด้วย Robotframework ทั้ง 4 ข้อนี้จะทำตามลำดับดังนี้

1. ทำการสร้าง MongoDB container ขึ้นมา

โดยสร้างแบบน่าเกลียดสุด ๆ ดังนี้ [code] $docker container run -d --name mongo mongo:3.5.13-jessie [/code] ปล. อย่าไปใช้บน production server นะ !!

2. ทำการสร้าง Backend container สำหรับ NodeJS

ในส่วนนี้เป็น RESTFul API พัฒนาด้วย NodeJS ซึ่งในครั้งนี้ทีมเลือกใช้ expressjs library มีข้อตกลงกันคือ ต้องทำการเขียนชุดการทดสอบด้วย ดังนั้นจึงทำการสร้าง Docker Image ใหม่ขึ้นมา เขียนใน Dockerfile ได้ดังนี้ [gist id="b1f9126d00619f7e0951e2234299788e" file="Dockerfile_backend"] คำอธิบาย
  • ทำการ copy ไฟล์ package.json ซึ่งเป็นไฟล์ config สำหรับ project
  • ทำการ copy ไฟล์ต่าง ๆ จาก folder src
  • ทำการ install library ต่าง ๆ ด้วย npm install
  • ทำการทดสอบด้วย npm test
  • ทำการ start ระบบงานแบบง่าย ๆ ถ้างานจริงแนะนำให้ใช้ pm2 นะ
ทำการสร้าง image ใหม่ชื่อว่า backend และ สร้าง container ดังนี้ [code] docker image build -t backend . $docker container run -d --name backend --link mongo backend [/code]

3. ทำการสร้าง Frontend container สำหรับ ReactJS

ในส่วนนี้ผมทำการแยกส่วนของการ compile และ build แยกออกมา โดยในการสร้าง frontend container จะใช้ nginx ซึ่งการ deploy นั้นทำง่าย ๆ คือ ทำการ copy ไฟล์ทั้งหมดใน folder build ไปยัง folder /usr/share/nginx/html เขียนใน Dockerfile ได้ดังนี้ [gist id="b1f9126d00619f7e0951e2234299788e" file="Dockerfile_frontend"] ทำการสร้าง image ใหม่ชื่อว่า frontend และ สร้าง container ดังนี้ [code] docker image build -t frontend . $docker container run -d --name frontend -p 80:80 -v $(pwd)/nginx.conf:/etc/nginx/nginx.conf --link backend frontend [/code] สิ่งที่เพิ่มเข้านิดหน่อยคือ ทำการ config nginx ให้เป็น reverse proxy นิดหน่อย สำหรับ REST API นั่นเอง ซึ่ง api จะขึ้นด้วย /api ตัวอย่างการ config ง่าย ๆ เป็นดังนี้ [gist id="b1f9126d00619f7e0951e2234299788e" file="nginx.conf"] เพียงเท่านี้เราก็ได้ระบบ Continuous Integration และ Deployment แบบง่าย ๆ แล้วนะครับ แต่งานจริง ๆ ยังต้องปรับปรุงอีกเยอะเลย ขอให้สนุกกับการ coding ครับ
↧

มาดูผลการสำรวจจาก RebelLabs Developer Productivity Report 2017

October 2, 2017, 1:42 am
$
0
0

เช้านี้อ่านผลสรุปเกี่ยวกับการสำรวจเรื่อง เครื่องมือและเทคโนโลยีสำหรับ Java Developer ว่ามีอะไรบ้างที่ช่วยเพิ่ม productivity ของการพัฒนา สามารถดูผลแบบเต็ม ๆ ได้ที่ RebelLabs Developer Productivity Report 2017: Why do you use the Java tools you use? หรือทำการ Download PDF มาอ่าน แถมมีข้อมูลดิบ ๆ มาให้ด้วยนะ เผื่อใครจะนำไปวิเคราะห์เพิ่มเติม มาดูสิ่งที่น่าสนใจจากผลการสำรวจครั้งนี้ดูหน่อยสิ

ข้อมูลพื้นฐานของผู้ทำแบบสำรวจ

การสำรวจในปี 2017 มีผู้ตอบจำนวน 2,060 คน มีรายละเอียดดังนี้
  • 103 ประเทศ แบ่งเป็น USA 15%, เยอรมัน 8%, UK 6%, อินเดีย และ บราซิล 5%
  • ทำงานในตำแหน่ง Developer 54%, Architect 18% และ Team Lead 17%
  • ขนาดของทีมที่ทำงาน 3-9 คนมาถึง 50%, 10-19 คนจำนวน 22% และ 20-49 คน จำนวน 9%
  • ประสบการณ์การทำงาน 6-15 ปีมากกว่า 50% โดยเฉลี่ยอยู่ที่ 13 ปี
  • ขนาดของบริษัทจะมีตั้งแต่ Enterprise 36%, ขนาดกลาง 30%, ขนาดเล็ก 21% และ StartUp 5%
จะมีหัวข้อต่าง ๆ ดังนี้
  • IDE ที่ใช้
  • ภาษา program หลักที่ใช้งาน (JVM language)
  • Application stack หรือ framework ต่าง ๆ ที่นำมาใช้งาน
  • Architecture ของระบบงาน
  • Database ที่ใช้งาน
มาดู IDE ที่ใช้ในการพัฒนา ซึ่งยังคงเป็น IntelliJ IDEA ที่ยังแรงต่อเนื่อง ส่วน Eclipse IDE ก็สวนทางกัน ส่วน NetBeans ก็ทรง ๆ ตัว แสดงดังรูป

ภาษาโปรแกรมสำหรับ Java Developer ส่วนใหญ่คือ Java 8 นะ

ปล. Java 5, 6 ไม่มีนะ หรือน้อยมาก ส่วนพวก Groovy, Scala และ Kotlin ซึ่งเป็น JVM language รวมกันยังไม่ถึง 10%เลย ส่วนภาษา Kotlin ที่กำลังได้รับความนิยมก็มีเพียง 1% เท่านั้น ยังคงเป็นส่วนน้อยมาก ๆ แปลกใจตรงที่ JavaScript มันมายังไง ? แต่ดูจากคนทำแบบสำรวจแล้ว อาจจะพอเกาได้จากประสบการณ์ทำงานก็ได้ !! ไว้ต้องไปดูข้อมูลแบบละเอียดอีกที แสดงดังรูป แต่เมื่อดูความพึงพอใจของนักพัฒนากลับพบว่า Kotlin และ Scala นำโด่งมาเลย

พวก framework ที่นิยมใช้งานก็ไม่หนีไปจาก Spring framework และ Java EE

Java EE กำลังจะ open source แล้วนะ ส่วนตัวอื่น ๆ ก็มีเล็กน้อยเช่น Dropwizard, SparkJava, Ratpack และ Play framework เป็นต้น อีกตัวที่น่าสนใจคือ Reactive ที่กำลังมา แสดงดังรูป

มาดู Architecture ของระบบกันหน่อย

ซึ่งมีหลายรูปแบบดังนี้
  • 34% ทำการแยกส่วนของ frontend และ backend ออกจากกัน
  • 25% ยังคงเป็นแบบ monolith
  • 23% เป็น Microservice
  • 8% เป็น SOA
  • 1% สำหรับ Serverless

ปิดท้ายด้วย Database ที่ใช้งานกัน ยังคงเป็น Oracle

มี MySQL และ PostgreSQL ตามมาติด ๆ ส่วนพวก NoSQL database มีประมาณ 10% เช่น MongoDB, Cassandra และ Redis เป็นต้น แต่ถ้ามองในแง่ของ Commercial vs Open source จะพบว่าเท่า ๆ กันเลยนะ แต่เอียงไปทาง Open source นิดหน่อย แสดงดังรูป

เมื่อพูดถึงการเปลี่ยนแปลง !!

พบว่าประมาณ 45% ไม่สามารถเปลี่ยนอะไรได้เลย เนื่องจากต้องแก้ไขระบบไปเรื่อย ๆ ตาม requirement และประมาณ 29% รู้ว่าสิ่งใหม่ ๆ มันดีนะ แต่ว่าเราไม่มีเงินและไม่มีเวลามาเปลี่ยน ที่น่าสนใจคือ มีเพียง 5% เท่านั้นที่บอกว่า ไม่มีเวลาศึกษา  
โดยรวมเป็นอีกอีกแหล่งข้อมูลที่น่าสนใจ สำหรับ Java Developer นะครับ
ขอให้สนุกกับการ coding ครับ
↧
↧

มาลองใช้งาน StackOverflow Bot จาก Microsoft กัน

October 3, 2017, 12:58 am
$
0
0

ทีมพัฒนาของ Microsoft ได้พัฒนา Bot สำหรับตอบคำถามหรือปัญหาต่าง ๆ โดยข้อมูลนำมาจาก StackOverflow สามารถใช้งานผ่าน Visual Studio Code ได้เลย น่าจะมีประโยชน์มาก ๆ สำหรับนักพัฒนา ดังนั้นมาดูกันว่าเป็นอย่างไรบ้าง ?

ประเด็นหลัก ๆ ของ Bot ตัวนี้คือ

การโชว์ของจาก Microsoft AI Platform และเครื่องมือต่าง ๆ ที่เกี่ยวกับ AI นั่นเอง ยกตัวอย่างเช่น
  • Bot framework
  • Cognitive Service
  • Cognitive Toolkit
  • Azure Machine Learning
  • Azure Service เช่น Bing custom search, LUIS, QnA Maker และ Text analytic
ตัวอย่าง source code ของ StackOverflow Bot

มาดูความสามารถของ Bot ตัวนี้กัน

สามารถรับข้อมูลในรูปแบบของ Text และ รูปภาพหรือ Screenshot ได้ จากนั้นจะตอบกลับเป็น Text ในภาษาอังกฤษ แสดงดัง VDO https://www.youtube.com/watch?v=d0ODT3feNw4

ข้อดีของ Bot คือ

ช่วยลดเวลาในการค้นหาสิ่งต่าง ๆ จาก StackOverflow ทำให้นักพัฒนามีเวลาในการเขียน code มากยิ่งขึ้น

การติดตั้ง StackOverflow Bot extension บน Visual Studio Code

ทางทีม Microsoft ไม่ยอมทำ plugin มาให้ใช้ง่าย ๆ แต่ก็บอกขั้นตอนการติดตั้งไว้ที่ Github Page สิ่งที่จำเป็นในการติดตั้งประกอบไปด้วย
  • NodeJs 8.14
  • ต้องไปสมัครสมาชิกที่ Microsoft Azure (ได้ 200 USD ฟรีนะ)
ลองเข้าไปดูใน folder StackBot สำหรับการสร้าง Bot มีไฟล์ Dockerfile ให้ด้วย ดังนั้นสร้าง Docker image ได้เลย จากนั้นก็สร้าง container ของ Bot มาใช้กันง่ายมาก ๆ [gist id="d39eaa9e610e24fece876a47e07876a5" file="install.txt"]

แต่ต้องไปเปิดใช้งาน service ต่าง ๆ จาก Microsoft เยอะมาก

ไม่รู้ว่าจะเยอะไปไหน ดังนี้
ผมลองไปเปิด service แล้วไม่รอดนะครับ !! ใครที่มีความพยายามกว่าผมก็ลองดูนะ
ขอให้สนุกกับการ coding นะครับ  
↧

ทำความรู้จักกับ Spring Boot Admin กันหน่อย

October 3, 2017, 6:26 pm
$
0
0

วันนี้น้องในทีมแนะนำให้รู้จัก Spring Boot Admin เมื่อลองไปดูพบว่ามันคือ ระบบจัดการและดูแลระบบงานที่พัฒนาด้วย Spring Boot พัฒนาโดยบริษัท Codecentric ยังไม่พอนะ มันยังมี User Interface ให้ใช้แบบง่าย ๆ อีกเพียบ ซึ่งในส่วนนี้พัฒนาด้วย AngularJS (เสียใจที่ไม่ใช่ Angular) แสดงข้อมูลได้เยอะเลย ยกตัวอย่างเช่น
  • แสดง health status ของแต่ละระบบหรือ service
  • แสดง Access log ของแต่ละ service
  • แสดง metric ต่าง ๆ เช่นการใช้งานแต่ละ service
  • แสดงการใช้งาน JVM และ memory ของแต่ละ service
  • การจัดารเกี่ยว Logging
  • ดูพวก thread dump และ tracing
  • มีระบบ notification ให้ด้วย
Spring Boot Admin ยังสามารถทำงานร่วมกับ พวก service registration และ service discovery เช่น Spring cloud, Zookeeper, Consul และ Eureka ได้อีกด้วย
อธิบายไปก็ไม่เห็นภาพ ดังนั้นลองใช้งานดีกว่า ตัวอย่างจะสร้างระบบแบบ Maven Project นะครับ

เริ่มต้นด้วยการสร้าง Spring Boot Admin ขึ้นมาก่อน

ซึ่งมันง่ายมาก ๆ มีขั้นตอนดังนี้ เริ่มด้วย library ต่าง ๆ ที่ใช้งานสำหรับ Spring Boot Admin [gist id="499aaa303f803d70a036d8358535951f" file="pom.xml"] จากนั้นสร้างไฟล์ Application.java สำหรับการเริ่มทำงานของระบบ [gist id="499aaa303f803d70a036d8358535951f" file="Application.java"] เมื่อทุกอย่างพร้อมทำการ run ระบบด้วยคำสั่ง [code] $mvn clean package $java -jar ./target/spring-boot-admin.jar [/code] ลองเปิดใช้งานผ่าน browser ด้วย url = http://localhost:8080/ หรือถ้าใครชอบใช้ Docker ผมก็มี Dockerfile ไว้ให้สร้าง Docker image ไว้ใช้เอง [gist id="499aaa303f803d70a036d8358535951f" file="Dockerfile"] จากนั้นทำการสร้าง Docker image และ container ด้วยคำสั่ง [code] $docker image build -t admin . $docker container run -d --name admin -p 8080:8080 admin [/code] ผลการทำงานก็จะเหมือนกัน หรือถ้าใครไม่อยากสร้าง Docker image เอง ก็สามารถไป pull มาจาก Docker hub ได้ แต่แบบนี้ไม่ดีนะครับ เนื่องจาก image ที่ได้มันใหญ่เกินไป !! แนะนำให้แยกระหว่างขั้นตอนการ build กับ run ออกจากกันด้วย Multi-stage ดีกว่า

จากนั้นทำการสร้าง Service ด้วย Spring Boot

โดย service ต่าง ๆ เหล่านี้จะทำการ register ไปยัง Spring Boot Admin แบบอัตโนมัติ ในส่วนนี้จะรองรับหลายแบบเช่น 1. แบบปกติคือกำหนด endpoint ของ Spring Boot Admin ใน service เลย 2. ใช้งานร่วมกับพวก Service discovery เช่น Eureka, Consul และ Zookepper เพื่อความง่ายจะเลือกแบบแรกมาสร้างระบบตัวอย่างให้ดู เริ่มด้วย library ต่าง ๆ ที่ใช้งานใน service จำเป็นต้องมี Spring Boot Actuator ด้วยสำหรับ health check และรายละเอียดต่าง ๆ ของ service [gist id="499aaa303f803d70a036d8358535951f" file="pom2.xml"] ต่อมากำหนด endpoint ของ Spring Boot Admin ในไฟล์ application.yml ดังนี้ ในตัวอย่างนี้จะยังไม่มีเรื่องของ security ใด ๆ เลย [gist id="499aaa303f803d70a036d8358535951f" file="application.yml"] เมื่อทุกอย่างพร้อมทำการ run service ด้วยคำสั่ง [code] $mvn clean package $java -jar ./target/service01.jar [/code] ผลที่ได้คือ เมื่อ service ทำการ start เรียบร้อยแล้ว จะทำการ register ไปยัง Spring Boot Admin ให้แบบอัตโนมัติ แสดงดังรูป

เข้าไปดูรายละเอียดของ service ผ่าน User Interface กัน

จะแสดงข้อมูลต่าง ๆ เพียบเลย เช่น Metric, Logging, JMX, Thread, Trace และ Heapdump เป็นต้น ตัวอย่างของ Logging ตัวอย่างของ Trace เพื่อดูการเข้าใช้งาน service และยังมีการแสดงการเปลี่ยนแปลงสถานะของ service อีกด้วยนะ ปล. ใน Google Chrome มี notification ด้วยนะ

มาถึงตรงนี้น่าจะพอทำให้เห็นความสามารถของ Spring Boot Admin บ้างนะ

น่าจะมีประโยชน์มากสำหรับการ monitoring service ต่าง ๆ ยิ่งถ้ามี service ที่พัฒนาด้วย Spring boot จำนวนมาก ๆ น่าจะอำนวยความสะดวกได้อีกมากเลย
ปล. ที่สำคัญ Spring Boot Admin สามารถทำ cluster ได้อีกด้วย ซึ่งจะทำการ replicate สิ่งต่าง ๆ ใน cluster ด้วย Hazelcast
ขอให้สนุกกับการ coding ครับ
↧

ใช้งาน Yarn ใน offline mode กัน

October 4, 2017, 9:06 am
$
0
0

ในการ build ระบบงานที่พัฒนาด้วย JavaScript และ NodeJS นั้น ปัญหาหลัก ๆ คือ เรื่องของการติดตั้ง library หรือ dependency ต่าง ๆ มันเยอะ ใช้เวลามาก แถมต้องทำการตรวจสอบผ่านระบบ network อีก ถ้าระบบ network มันช้าละ จะยิ่งช้ากว่าเดิมไหม ? ดังนั้น Yarn จึงได้เตรียม offline mode หรือ caching พวก node modules มาให้ใช้ แน่นอนว่า ใช้ไม่ได้ยากเลย ดังนี้

เริ่มต้นด้วยการกำหนดที่จัดเก็บ caching ของ node module

[code] $yarn config set yarn-offline-mirror ./yarn-offline-cache [/code] คำอธิบาย ทำการระบุ folder ไปที่ ~/yarn-offline-cache โดยสิ่งที่เก็บคือไฟล์ tar.gz ของ library หรือ dependency แต่ละตัว แสดงดังรูป

ยังไม่พอนะจะสร้างไฟล์ ~/.yarnrc ขึ้นมา

เพื่อจัดเก็บ configuration ของ yarn offline นั่นเอง ดังนี้ [code] # THIS IS AN AUTOGENERATED FILE. DO NOT EDIT THIS FILE DIRECTLY. # yarn lockfile v1 lastUpdateCheck 1507093606866 yarn-offline-mirror "./yarn-offline-cache" [/code]

มาถึงตรงนี้ทุกครั้งที่ใช้คำสั่งของ yarn

จะทำการตรวจสอบที่ folder caching ที่กำหนดไว้ก่อน จากตัวอย่างคือ ~/yarn-offline-cache แต่ถ้าไม่เจอ ก็จะไป download มาจาก public repository เพื่อมาเก็บใน folder นี้ เพียงเท่านี้การ build project ก็เร็วขึ้นเป็นกองแล้วครับ ที่สำคัญไม่จำเป็นต้องต่อ internet อีกแล้ว (ถ้าไม่เปลี่ยนแปลงนะ) ขอให้สนุกกับการ coding ครับ
↧
Viewing all 1997 articles
Browse latest View live
Search