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

ทำการสร้าง Intelligence Mobile app ?

December 25, 2016, 8:12 pm
$
0
0

มีโอกาศพูดคุยเรื่องการสร้าง Mobile app ให้ฉลาด ๆ ด้วยการนำ Machine Learning เข้ามาช่วย ซึ่งคิดว่าเป็นเรื่องที่ไม่ได้ไกลตัวเลย ดังจะเห็นได้จากบริษัทใหญ่ ๆ เริ่มพัฒนาระบบออกมาให้ใช้กันเยอะ เช่น
  • Google Assistance
  • Apple Siri
  • Microsoft Cortana
  • Amazon Alexa
  • Self-driving car
  • Robot/Chat bot
รวมถึง app ต่าง ๆ ก็นำมาช่วยเพื่อปรับปรุงระบบ รวมทั้งประสบการณ์การใช้งานต่าง ๆ แน่นอนว่า เป้าหมายเพื่อทำให้ผู้ใช้งานสะดวกบายมากยิ่งขึ้น
คำถามที่น่าสนใจคือ ในมุมมองของนักพัฒนาจะพัฒนาระบบเหล่านี้กันอย่างไรดีล่ะ ?

เมื่อลองไปค้นหาเครื่องมือสำหรับพัฒนาระบบให้ฉลาด ๆ

ไม่ว่าจะเป็น
  • Speech recognition
  • Face detection
  • Natural Language Processing (NLP)
  • Prediction

การพัฒนาใหม่ตั้งแต่ศูนย์อาจจะเหนื่อยมากหน่อย (แต่คุ้มสำหรับการเรียนรู้นะ)

แต่ถ้าต้องการลดเวลาการเรียนรู้และค่าใช้จ่ายต่าง (ค่าชาค่ากาแฟ) ก็มี platform และ service ต่าง ๆ ไว้ให้ใช้งานกันพอควรนะ ตัวอย่างเช่น ซึ่งน่าจะช่วยให้ชีวิตของนักพัฒนาสะดวกมากยิ่งขึ้น แต่สิ่งสำคัญคือ การเรียนรู้เรื่องพื้นฐานที่ขาดไปเสียมิได้เลย
วันนี้นักพัฒนาเริ่มเรียนรู้เกี่ยวกับ Intelligence App กันหรือยัง ?
↧
Search

เรื่องเล่น ๆ เราจริงจังมากกับสิ่งที่ Developer ชอบพูด !!

December 26, 2016, 6:59 am
$
0
0

พอดีไปเจอ web CodingExcuses ที่สรุปประโยคที่ developer ชอบพูด เมื่อเกิดข้อผิดพลาดหรือสิ่งใดก็ตามที่กระทบกับตัวเอง มักจะโทษสิ่งอื่น ๆ ยกเว้นตนเอง เช่น โทษเครื่องมือที่ใช้ โทษ vendor โทษคนอื่น ซึ่ง web นี้ได้ทำการเปิดเผย source code [Bad Tool] นะครับ ทำให้ใครก็ตามทำการ fork และนำไปแก้ไข และใช้งานกันแบบง่าย ๆ ได้เลย เนื่องจากมี APIs ให้ใช้งาน โดยรูปแบบข้อมูลมีทั้ง Text, JSON, XML, JSONP ใครมีประโยคเด็ด ๆ ก็สามารถเพิ่มเข้ามาได้นะ สามารถแก้ไขได้ในไฟล์ Data.yaml
↧
↧

เรียนรู้ภาษาโปรแกรมใหม่ ๆ ด้วย Koan กันดีกว่า

December 28, 2016, 6:36 am
$
0
0

การเรียนรู้ภาษาโปรแกรมใหม่ ๆ มีหลายวิธีการมาก ๆ หนึ่งในนั้นคือ Koan ซึ่งจะมีปัญหาและแบบฝึกหัดให้ทำ ตั้งแต่ง่ายไปยากเรียงตามหัวข้อไป ทำให้การเรียนรู้ภาษาโปรแกรมใหม่ ๆ สนุกขึ้น จึงทำการสรุป Koan ที่น่าสนใจไว้ให้หน่อย

เมื่อลองทำการค้นหาจะพบ Koan ของแต่ละภาษาเยอะมาก

ดังนี้

ยังไม่พอนะ ในปัจจุบันยังมี Testing Koan อีกด้วย

นั่นคือการเรียนรู้ภาษาใหม่ ๆ จาก Unit testing ในแต่ละภาษานั่นเอง ตัวอย่างเช่น

โดยรวมแล้ว Koan เป็นอีกแนวทางหนึ่งของการเรียนรู้ที่ดีมาก ๆ

ซึ่งมีปัญหาและแบบฝึกหัดต่าง ๆ ให้ลงมือทำ ตั้งแต่ง่ายไปหายาก รวมทั้งยังมี feedback loop ที่รวดเร็วอีกด้วย นั่นคือ ทำให้เราเรียนรู้ได้รวดเร็วอย่างมาก
วันนี้เราได้เรียนรู้และฝึกฝนกันบ้างหรือไม่ ?
↧

สรุปแนวโน้มที่น่าสนใจการจัดการข้อมูลในปี 2017 จาก Oreilly

December 29, 2016, 7:14 am
$
0
0

ข้อมูลจาก Data community ของ Oreilly ทำการสรุปแนวโน้มในปี 2017 ออกมาได้อย่างน่าสนใจ ทั้งเรื่องของ Data scientist ทั้งเรื่องของ Data engineering ทั้งเรื่องของ Data stroage ทั้งเรื่องของเครื่องมือต่าง ๆ จึงทำการแปลและสรุปไว้นิดหน่อยดังนี้

1. Data scientist เริ่มนำ Deep learning มาใช้กันมากขึ้น

ในปี 2016 นั้นเทคโนโลยีที่เกี่ยวกับ Deep learning พัฒนาไปอย่างมาก ตลอดจนบริษัทต่าง ๆ ได้ออกเครื่องมือเกี่ยวกับ Deep learning ออกมามากขึ้น ทำให้การเรียนรู้และการใช้งานง่ายมากขึ้น แน่นอนว่า เครื่องมือต่าง ๆ เหล่านี้ ต้องสามารถ integrate เข้ากับพวก Big data tools และ framework ได้เป็นอย่างดี ดังนั้นจะสอดคล้องกับเรื่องข้อมูลพวก time serie, event based ที่มาจากอุปกรณ์ IoT และ sensor ต่าง ๆ ที่มีจำนวนมากขึ้น ยิ่งนำ Deep learning มาช่วยจะก่อให้เกิดประโยชน์ขึ้นมากมาย
ดังนั้นในปี 2017 นั้นเรื่อง Deep learning คงเป็นสิ่งที่ Data scientist ทุกคนพลาดไม่ได้เลย

2. Data engineering จะมีความต้องการสูงอย่างมาก

ยิ่ง Data scientist เป็นงานที่มีความต้องการสูงแล้ว ยิ่งทำให้เกิดช่องหว่างหนึ่งในองค์กรขึ้นมา นั่นคือ Data scientist ที่สามารถเขียน code ได้ Data scientist ที่สามารถแก้ไข code ได้ นั่นคือ Data engineering นั่นเอง Data scientist ที่ว่ายากแล้ว Data engineering นี่ยากกว่า ดังนั้น developer ที่ต้องการความท้าทายแนะนำเป็นอย่างยิ่ง

3. บริษัทต่าง ๆ เริ่มนำ service ไปอยู่บนระบบ Cloud มากขึ้น

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

4. แต่อย่าลืมว่า ข้อมูลบางอย่างมันก็เอาขึ้น public cloud ได้นะ !!

เช่น Legacy system, sensitive data และ security รวมไปถึง privacy issue ต่าง ๆ ดังนั้นสิ่งที่เกิดขึ้นคือ การ mix หรือรวมกันระหว่างระบบปกติกับ public cloud หรือกลายเป็น hybrid application นั่นเอง หรือบางครั้งต้องใช้งาน private cloud จาก cloud provider ต่าง ๆ ดังนั้นองค์กรต่าง ๆ จำเป็นจะต้องมี solution architect ที่มีความเข้าใจกับเรื่องต่าง ๆ เหล่านี้ ปล. ถ้ายังไม่เคยใชงานระบบ cloud เลยก็จะลำบากมาก ๆ นะ สำหรับ solution architect !!

5. มีเครื่องมือต่าง ๆ ขึ้นมา ซึ่งทำให้งานที่ยากกลายเป็นเรื่องที่ง่ายขึ้นมาก ๆ

เครื่องมือสมัยใหม่นั้นมีทุกอย่างให้ครบ เพียงแค่ใส่ข้อมูลที่ถูกต้องเข้าไปให้ บางตัวผู้ใช้งานไม่จำเป็นต้องรู้การเขียน code ก็ใช้ได้ บางตัวผู้ใช้งานไม่จำเป็นต้องเชี่ยวชาญเรื่องของสถิติก็ใช้งานได้ ตัวอย่างเช่น
  • Amazon Machine Learning
  • Google Cloud Platform
  • Microsoft Azure

6. แยกส่วนการทำงานระหว่าง Data Storage และ Data computation ออกจากกันอย่างชัดเจน

เนื่องจากแต่ละส่วนมีการทำงานและความต้องการต่างกันไป จะรวมเข้าไว้ด้วยกันคงไม่ดีอย่างแน่นอน

7. พวก Notebooks และ workflow tool ต่าง ๆ ยังคงถูกพัฒนาต่อไป

ตัวอย่างที่เห็นได้ชัดคือ Jupyter notebook เป็นสิ่งที่ Data scientist นิยมใช้กันอย่างมาก เนื่องจากมีทุกสิ่งอย่างที่จำเป็นต่อการใช้งาน แถมใช้งานง่ายอีกต่างหาก ตั้งแต่แบ่งปันเอกสารการใช้งาน source code สูตรต่าง ๆ แสดง Visualization และผลสรุปต่าง ๆ ซึ่งมีประโยชน์ต่อทีมอย่างมาก แน่นอนว่ายังมีเครื่องมืออื่น ๆ มาใช้งานอีก เช่น Beaker notebook ซึ่งสนับสนุนภาษาโปรแกรมจำนวนมาก แต่สิ่งหนึ่งที่ notebooks ต่าง ๆ จะต้องมีคือ การเชื่อมต่อหรือทำงานร่วมกับ Spark แต่ใช่ว่าทุกคนจะใช้ notebooks นะ เพราะว่างานบางอย่างที่ซับซ้อนก็ใช้ไม่ได้เช่นกัน หรือ Data Engineering อาจจะต้องใช้เครื่องมือเหมือนกับ developer ก็ได้ แต่โดยรวมแล้วพวก notebooks และ workflow tool ต่าง ๆ จะยังคงพัฒนาต่อไปอีก ทั้งจากเรื่องของ Deep learning รวมทั้งกับเทคนิคและวิธีการใหม่ ๆ ที่เกิดขึ้นมาเยอะเหลือเกิน

สุดท้ายแล้วเรื่องของ Privacy และ Ethic (จริยธรรมหรือจรรยาบรรณ) ของการนำข้อมูลไปใช้งาน

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

สรุปการเขียน blog ในปี 2016 มาเขียนวันละ blog กัน

December 30, 2016, 8:41 pm
$
0
0

ทำการสรุปสถิติต่าง ๆ สำหรับการเขียน blog ที่ somkiat.cc ในปี 2016 ไว้นิดหน่อย เป้าหมายหลักของการเขียนคือ สรุปสิ่งที่สนใจในแต่ละวัน สรุปสิ่งที่ลงมือทำในแต่ละวัน สรุปสิ่งที่ศึกษาในแต่ละวัน และทำการบันทึกไว้อ่านนั่นเอง โดยมีตัวเลขที่น่าสนใจดังนี้
  • จำนวน blog ทั้งหมด 280 blog น้อยกว่าปี 2015 ไปเกือบ 50 blog !! ต้องปรับปรุง
  • เรื่องที่เขียนส่วนมากจะเป็นเรื่องของ programming เป็นหลัก คือ Java, Android, Swift
  • มีสรุปการแบ่งปันในงาน meetup ต่าง ๆ ที่เกิดขึ้นตลอดปี
มาดูรายละเอียดกันนิดหน่อย

ภาพรวมทั้งปีจาก Google Analytic ก็แค่นี้แหละ

Browser ที่เข้าใช้งานหลัก ๆ ยังคงเป็น Google Chrome

ตามมาด้วย Safari และ Firefox

ระบบปฏิบัติการหลักยังคงเป็น Windows

แต่ถ้าสังเกตุให้ดีจะพบว่า Desktop กับ Mobile นี่ 50-50 เลยนะ

ส่วนของการเข้าดูผ่าน Mobile ยังคงเป็น Android และตามด้วย iOS

ส่วน Traffic หลัก ๆ มาจาก Social คือ Facebook นั่นเอง

รองลงมาคือ Organic search และ Direct

Blog ที่มีคนเข้ามาอ่านเยอะ ๆ มีดังนี้ (หายากมาก ๆ)

ขอให้สนุกกับปีใหม่ครับ แล้วมาเขียนวันละ blog กันนะ
↧
↧

VDO เรื่อง Git สำหรับผู้เริ่มต้นใน 7 นาที พร้อม Infographic เข้าใจง่าย ๆ

December 30, 2016, 11:18 pm
$
0
0

ไปเจอ VDO สอนพื้นฐานการใช้งาน Git ที่ CodingDojo.com ทำการอธิบายได้สั้นและกระชับภายใน 7 นาที จึงทำการแปลและสรุปไว้นิดหน่อย น่าจะมีประโยชน์สำหรับผู้เริ่มต้น ในปัจจุบันการจัดการ version ของข้อมูลถือว่าสำคัญมาก ๆ source code ของการพัฒนา software ก็เช่นกัน ซึ่งมีให้เลือกมากมาย แต่ที่ได้รับความนิยมมาก ๆ ประกอบไปด้วย SVN และ Git แสดงดังรูป โดย VDO สามารถดูได้ที่นี่ https://www.youtube.com/watch?v=gl9bIJbW9Eg ปิดท้ายด้วยรูป infographic นิดหน่อย น่าจะเป็นประโยชน์สำหรับผู้เริ่มต้นเรียนรู้ Git นะครับ
↧

ทำไม Developer ควรให้เวลากับการลบ code ของตัวเองทิ้งไปบ้าง ?

January 2, 2017, 3:50 am
$
0
0

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

เริ่มต้นด้วยการเขียน code แบบให้เสร็จ ๆ ไป

ไม่สนใจว่ามันคือ Bad practice ในการเขียน code นะ ทำการ comment เพื่ออธิบาย code ก็ได้ เขียน code ยาว ๆ เขียน code ซับซ้อน แต่ code ทำงานได้นะ !! สุดท้ายก็พบว่า code เหล่านี้จะถูกลบและเขียนใหม่ทั้งสิ้น code เหล่านี้จะถูกมองว่าเป็นปีศาจ บางคนอาจจะเรียกว่าซอมบี้ก็ได้ เนื่องจากฆ่าไม่ตาย ยิ่งแก้ยิ่งผิด คนที่ตายหรือเจ็บปวดคือ คนแก้ ไม่เว้นแม้กระทั้งคนสร้าง

ต่อมาของ code ที่แย่ ๆ เกิดจาก เวลามีจำกัด

ทุก ๆ ระบบมีขอบเขตเวลาที่จำกัด บางทีม Developer ไม่มีสิทธิ์มีเสียงเรื่องขอบเขตของเวลา ถูกกำหนดโดยคนที่ไม่ได้เขียน code ดังนั้นคนเขียน code ต้องเขียนให้เสร็จในกรอบเวลาที่กำหนด โดนเวลากดดัน หรือโดนสิ่งที่เรียกว่า deadline เล่นงาน
ผลที่ตามมาคือ code ห่วย ๆ ชุดหนึ่ง
ปล. พบว่าผลที่ตามมาจาก code เหล่านี้หนักมาก ๆ Bug มากมาย Code มั่วซั่ว แถมใช้เวลาในการแก้ไขมากกว่าเวลาการสร้างเสียอีก แต่ก็ยังคงไม่สนใจกันอีก แถมไม่นำข้อมูลเหล่านี้ไปดูอีกด้วย เพราะว่าสนใจเพียงแค่แผน
คำถามคือ ถ้าเกิดปัญหาขึ้นมาใครผิด ? แน่นอนว่าก็ต้องคือคนเขียนสิ !! โดนทั้งขึ้นทั้งล่อง

ต่อมาเรื่องที่ Developer ไม่ค่อยจะทำคือ Planning (ไม่ใช่ plan ที่นิ่งนะ)

ถ้าเราต้องการลดค่าใช้จ่าย เวลา และ effort ในการพัฒนา software ลงแล้ว สิ่งที่จำเป็นอย่างมากคือ การวางแผนในสิ่งที่จะทำ ว่าทำอะไร เพื่ออะไร เกี่ยวข้องกับระบบใด ๆ บ้า จะทดสอบอย่างไร และอื่น ๆ อีกมากมาย มันคือความใส่ใจในสิ่งที่ทำ การวางแผนงานก็เช่น การออกแบบระบบ ซึ่งถ้าออกแบบหรือวางแผนไม่ดี ผลที่ตามมาคือ จะมี code ที่ไม่จำเป็นเกิดขึ้นมามากมาย หรือยากต่อการเปลี่ยนแปลงอย่างมาก รวมทั้งการเปลี่ยนแปลงต่าง ๆ มันส่งผลกระทบต่อ ภายในและภายนอกระบบหรือไม่ ? ถ้าไม่รู้หรือไม่แน่ใจแสดงว่า คุณวางแผนได้แย่มาก ๆ ต้องทำการปรับปรุงแล้วนะ จากนั้นก็คือพฤติกรรมของ Developer ว่าเป็น Copy and Paste programmer หรือไม่ ?

ดังนั้นสิ่งที่ Developer ควรให้ความสำคัญ

ไม่ใช่ที่จำนวน Line of Code (LoC) แต่เป็นเรื่องของคุณภาพของ code ที่เขียนออกมามากกว่า เนื่องจาก Developer ส่วนใหญ่ ไม่ค่อยให้ความสนใจเรื่องคุณภาพ แต่กลับไปสนใจที่ solution หรือวิธีการที่เร็ว ๆ หรือบางคนชอบเรียกว่า สูตรลัดนั่นเอง

เมื่อเรารู้แล้วว่าสาเหตุของการสร้าง code ที่ต้องโดนลบหรือแก้ไขมาจากไหน

เราก็น่าจะหาวิธีป้องกันหรือลดจำนวน code ลงไปได้นะ เพราะว่าการมาลบหรือแก้ไข code มันไม่ง่ายเลย แถมยากต่อการประเมินอีกด้วยว่าต้องใช้เวลาเท่าไร
วันนี้ Developer เป็นอย่างไรกันบ้างนะ ?
↧

เริ่มต้นการเขียน unit test สำหรับ JavaScript ด้วยการติดตั้ง

January 2, 2017, 9:39 pm
$
0
0

พอดีต้องพัฒนาระบบด้วย JavaScript ซึ่งต้องนำ Webpack มาใช้ด้วย สิ่งแรกที่ต้องการคือ การเขียน unit test เมื่อไปค้นหาก็เจอบทความเกี่ยวกับ Mocha + Webpack เยอะเลย ส่วน assertion ก็นำ chai มาช่วยนิดหน่อย มาเริ่มกันเลย

เริ่มจากความต้องการสำหรับการทดสอบ

  • ทำการสร้างได้อย่างง่าย
  • ทำการทดสอบได้อย่างรวดเร็ว
  • ทำงานใน terminal
  • ทำการบันทึกชุดการทดสอบแล้ว ให้ทำการทดสอบเองทันที
จากนั้นลองมือสร้างกันดีกว่า

ขั้นตอนที่ 1 ทุก ๆ test case จะอยู่ใน directory ชื่อว่า tests

สามารถเขียน code ง่าย ๆ ได้ดังนี้ อยู่ในไฟล์ all-tests.js [gist id="fe66d5bd0f1b9b03fa99dd0a1820bebf" file="all-tests.js"]

ขั้นตอนที่ 2 สิ่งที่ต้องการคือ ทำการทดสอบหลังจากที่ build webpack เสร็จ

ดังนั้นสิ่งที่ต้องการใช้คือ webpack-shell-plugin ให้ทำการติดตั้งผ่าน npm ซะ จากนั้นทำการ configuration ในไฟล์ชื่อว่า webpack-test.config.js ดังนี้ [gist id="fe66d5bd0f1b9b03fa99dd0a1820bebf" file="webpack-test.config.js"]

ขั้นตอนที่ 3 ทดสอบการใช้งาน

สามารถ run ด้วยคำสั่ง [code] $webpack -w --config webpack-test.config.js [/code] หรือ [code] $npm test [/code] จะแสดงผลการทำงานดังนี้

ขั้นตอนที่ 4 ลองเพิ่มชุดการทดสอบและบันทึกซะ

ระบบจะทำการ build และ ทดสอบให้แบบอัตโนมัติดังรูป
เพียงเท่านี้น่าจะทำให้การเขียน unit test เป็นเรื่องที่สนุกมากยิ่งขึ้น Let’s coding with tests
ตัวอย่างของ project อยู่ที่ Github::Up1::Unit test with JavaScript Reference Websites https://dzone.com/articles/unit-testing-with-webpack-amp-mocha
↧
Search

Infographic ที่น่าสนใจเกี่ยวกับ Software development

January 3, 2017, 1:50 am
$
0
0

เห็นรูป infographic สวย ๆ เพื่อใช้อธิบาย เกี่ยวกับ Software development หรือการพัฒนา software จาก DZone :: The World of Software Development Explored in 10 Infographics มีสิ่งที่น่าสนใจ 3 รูปดังนี้

รูปแรกคือ Home of release pain points

เป็นผลจากการสำรวจเรื่องความเจ็บปวดของการ release software ว่าส่วนใหญ่ต้องประสบกับสิ่งใดบ้าง สามารถสรุปสั้น ๆ ได้ดังนี้ 1. การ configuration และ setup environment ต่าง ๆ ที่แย่ 2. กระบวนการ deploy ที่ไม่ดี 3. การจัดการที่ห่วย 4. ปัญหาเรื่อง requirement 5. ปัญหามาจาก User Acceptance Test สิ่งที่พบคือ สิ่งที่สร้างกับสิ่งที่ผู้ใช้ต้องการคนละเรื่อง แสดงดังรูป

รูปที่สอง เรื่องรูปแบบการโจมตีระบบงาน

ซึ่งมาจากผลการสำรวจเช่นกัน โดยมีรูปแบบการโจมตีหลัก ๆ 7 รูปแบบ ประกอบไปด้วย 1. SQL Injection 2. DDoS (Distributed Denial of Service) 3. Phishing 4. XSS (Cross-Site Script) 5. Man-In-The-Middle 6. CSRF (Cross-Site Request Forgery) 7. Trojan แสดงดังรูป

รูปที่สามเรื่องของ 12 factor app https://12factor.net/

ซึ่งในปัจจุบันถูกพูดหรือกล่าวถึงกันบ่อยมากขึ้น ประกอบไปด้วย 12 เรื่องคือ 1. Codebase 2. Dependencies 3. Config 4. Backing services 5. Build, release, run 6. Processes 7. Port binding 8. Concurrency 9. Disposability 10. Dev/prod parity 11. Logs 12. Admin processes แสดงดังรูป
↧
↧

Kata Java :: ฝึกกรองและเรียงลำดับข้อมูลใน List

January 4, 2017, 12:02 am
$
0
0

จาก post การพูดคุยเรื่องทำการกรองและเรียงลำดับข้อมูลใน List กันอย่างไร ? ใน Facebook group ของ Thailand Android Developer ซึ่งมีความน่าสนใจมาก ๆ จึงมาลองฝึกเขียนตามคำแนะนำใน comment กันหน่อย โดยจะเป็นภาษา Java และ Kotlin ซึ่งมีวิธีการแก้ไขดังนี้
  1. เขียนด้วยภาษา Java ทั่วไป
  2. เขียนด้วย Java 8 Lambda
  3. เขียนด้วยการนำ Google Guava มาช่วย
  4. เขียนด้วยการนำ RxJava มาช่วย
  5. เขียนด้วยภาษา Kotlin
มาเขียน code กัน ที่สำคัญมี test นะเออ

วิธีการที่ 1 เขียนด้วย Java ปกติ

ในการกรองข้อมูลก็วน loop กันไป ในการเรียงข้อมูลก็สร้าง class ที่ implement interface Comparator ไปตามระเบียบ [gist id="9d1c81e7a4a9da73662f0feec236150b" file="1.java"]

วิธีการที่ 2 เขียนด้วย Java 8 Lambda

เอา code มาจากใน comment ของ post ข้างต้นนั่นแหละ เป็นการใช้ Stream API นั่นเอง [gist id="9d1c81e7a4a9da73662f0feec236150b" file="2.java"]

วิธีการที่ 3 ใช้ Google Guava

ก็นำเอาความสามารถของ Java8 Lamba มาใช้ด้วย [gist id="9d1c81e7a4a9da73662f0feec236150b" file="3.java"]

วิธีการที่ 4 ใช้ RxJava

อาจจะดูแปลกตาขึ้นมาอีก แต่ว่าได้รับความนิยมเยอะนะ [gist id="9d1c81e7a4a9da73662f0feec236150b" file="4.java"] สามารถเขียน test เพื่อทดสอบได้ดังนี้ [gist id="9d1c81e7a4a9da73662f0feec236150b" file="alltest.java"] ได้ผลการทดสอบผ่าน JUnit ดังนี้ [code] <testcase classname="kata.SimpleTest" name="withSimpleSolution" time="0.014"/> <testcase classname="kata.SimpleTest" name="withGuavaSolution" time="0.049"/> <testcase classname="kata.SimpleTest" name="withRxJavaSolution" time="0.038"/> <testcase classname="kata.SimpleTest" name="withJava8Solution" time="0.01"/> [/code] ตัวอย่าง source code อยู่ที่ Github::Up1::Java Filter and Sort

ปิดท้ายด้วยภาษา Kotlin กันหน่อย ทำไมมันสั้นจังนะ

[gist id="9d1c81e7a4a9da73662f0feec236150b" file="5.kt"] จบแล้วก็ได้ฝึกเขียน code กันอีกเรื่องแล้ว ซึ่งแน่นอนว่ายังมีวิธีการอื่น ๆ ที่ดีอีกมากมาย ใครมีคำแนะนำดี ๆ บอกกันได้นะครับ
↧

มาเพิ่ม productivity ให้กับการพัฒนา Android App กัน

January 5, 2017, 12:01 am
$
0
0

การพัฒนา software ที่ว่าทำได้เร็วแล้ว การพัฒนา Mobile app ยิ่งต้องการความรวดเร็วกว่ามาก ดังนั้น Mobile developer จำเป็นต้อง รับรู้ข่าวสารการเปลี่ยนแปลงต่าง ๆ ได้อย่างรวดเร็ว ลอง เล่น ใช้ ทิ้ง ให้เป็น เพื่อทำการปรับปรุงตัวเองและระบบงานต่อไป โดยเฉพาะ Android Developer ด้วยแล้วจำเป็นต้อง เรียนรู้และปรับปรุงตัวเองอยู่อย่างเสมอ ทั้งการเขียน code ให้ดีและมีคุณภาพ ทั้งการทดสอบ app ที่พัฒนา ทั้งการใช้เครื่องมือในการพัฒนาต่าง ๆ ทั้งการรีดศักยภาพของเครื่องมือออกมาใช้งานให้ดีที่สุด
เพื่อทำให้เราเร็วขึ้น แต่ไม่รีบเร่งนะ !! มาเริ่มกันเลย

เรื่องที่ 1 คือการใช้งาน Shortcut ใน Android Studio

เป็นสิ่งที่นักพัฒนาควรฝึกซ้อมไว้จนเป็นนิสัย ถ้ายังไม่ฝึกก็เอา Reference Card ไปฝึกเลย ผมใช้ Mac นะ ส่วน Linux และ Windows

เรื่องที่ 2 คือ Live template ใน android Studio

ซึ่งช่วยลดการเขียน code ลงไปได้อย่างมาก นั่นคือจะช่วยทำให้เราเร็วขึ้น ปล. ต้องรู้และเข้าใจการใช้งานด้วยนะ สามารถศึกษาเพิ่มเติมได้ที่นี่ Android Studio Live Template รวมทั้งการ configuration เรื่องอื่น ๆ ที่น่าสนใจอีกมากมาย ปล. คนจริงต้องใช้ Canary channel นะครับ !! พังเร็วดี แต่ใช้งาน feature  ใหม่ ๆ ก่อนใคร

เรื่องที่ 3 การเลือกใช้ plugin ใน Android Studio ก็สำคัญ

อ่านเพิ่มเติมได้ที่ Tip and trick ของการใช้ plugin List of pligins

เรื่องที่ 4 คือ Emulator

ในตอนนี้น่าจะมีอยู่สองตัวหลัก ๆ ที่ใช้งานกันคือ Genymotion และ Android Emulator แต่ถ้าพูดถึงเรื่องความเร็วก็ต้องยกให้ Genymotion ส่วน Android Emulator ตามมาติดติดพร้อม feature ที่หลากหลายเช่นกัน ลองดูว่าชอบแบบไหน ลองดูว่าแบบไหนเร็วกว่า ลองดูว่าแบบไหนเหมาะกว่า

เรื่องที่ 5 คือการเพิ่มความเร็วให้กับ Gradle !!

เป็นเรื่องที่ไม่ง่ายเลย เพราะว่า Gradle มันขึ้นชื่อเรื่อง build นานอยู่แล้ว แต่ถ้าเราสามารถลดเวลาการ build ได้ ก็จะช่วยให้เราเร็วขึ้นไปอีก ปล. ลดจำนวน method count ก็ช่วยให้ build เร็วขึ้นไปอีกนะ สามารถอ่านรายละเอียดเพิ่มเติมได้ที่ Reduce build time Build time tracker Speed up your gradle Gradle performance guide

เรื่องที่ 6 นำเครื่องมือพวก 3-parties มาใช้งานบ้างนะ

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

เรื่องที่ 7 เรียนรู้การใช้ ADB command (Android Device Bridge)

เนื่องจากถ้าเราใช้งาน adb command ได้อย่างคล่องแคล่วแล้ว จะสามารถควบคุม device ได้อย่างง่าย ๆ เลย ทั้งการปลด lock หน้าจอ ทั้งการ capture หน้าจอ ทั้งการควบคุมการใช้งาน ทั้งการลบและติดตั้ง app และอื่น ๆ อีกมากมาย สามารถอ่านรายละเอียดเพิ่มเติ่มได้ที่ Google :: ADB Google :: Shell

สุดท้ายแล้วต้องทดสอบบน Emulator และ Device ที่หลากหลายด้วยนะ

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

มาดูแผนการ release ของ Angular 4 กันหน่อย

January 5, 2017, 7:52 pm
$
0
0

ในตอนนี้ Angular เป็น version 4 beta 2 แล้วนะ ซึ่งผู้พัฒนาบอกว่า อย่าเรียกว่า AngularJS อย่าเรียกว่า Angular 2 อย่าเรียกว่า Angular 4 อย่าเรียกตาม version แต่บอกให้เรียกว่า Angular เท่านั้น เนื่องจากมีการ release และเปลี่ยน version บ่อย ดังนั้นเพื่อไม่ให้สับสนก็เรียกสั้น ๆ ไปก็พอ

โดยที่ Angular version 4 นั้นมีแผนในการ release คือ

ช่วงระหว่างเดือนธันวาคม 2559 ถึง เดือนกุมภาพันธ์ 2560 จะมี beta release ออกมา 8 ครั้ง จากนั้นจึงเป็น Release Candidate (RC) อีก 2 ครั้งในเดือนกุมภาพันธ์ 2560 และตัวเต็ม ๆ จะปล่อยออกมาต้นเดือนมีนาคม 2560

คำถามคือ แล้ว version 3 ไปไหน ?

น่าจะได้คำตอบจาก slide หน้านี้

ยังไม่พอนะ มีแผนในการปล่อย version อื่น ๆ ออกมาอีก ดังนี้

เดือนกันยายนถึงตุลาคม 2560 จะปล่อย version 5 เดือนมีนาคม 2561 จะปล่อย version 6 เดือนกันยายนถึงตุลาคม 2561 จะปล่อย version 7

แล้วมันจะ Backward compatibility หรือเปล่านะ ?

จาก VDO ด้านล่างผู้พัฒนาบอกว่า จะพยายามให้มัน Backward compatibility กับ Angular version 2 ให้ได้มากที่สุดเท่าที่จะเป็นไปได้ เนื่องจากเรื่องของ Ecosystem ที่มัน stable สำคัญมาก ๆ รวมทั้งทำการปรับปรุง error message ต่าง ๆ ของ compiler ให้เข้าใจง่ายขึ้น
แถมจะทำการยกเครื่อง Angular จากพัฒนาด้วย TypeScript จาก 1.8 ไปยัง 2.1 ซึ่งถือว่าเป็นอีกหนึ่ง breaking change กันเลย !!
สำหรับ Angular Developer น่าจะเห็นแล้วว่า ต้องรับมือกับการเปลี่ยนแปลงเหล่านี้กันอย่างไรนะครับ

ปล. มีการอธิบายเรื่อง Semantic version ของ Angular เป็นดังรูป

ดู VDO การเปิดตัว Angular version 4 ได้ที่นี่ https://www.youtube.com/watch?v=aJIMoLgqU_o  
↧

Feature ที่น่าสนใจในภาษา Go 1.8 (beta 2)

January 9, 2017, 6:34 am
$
0
0

ภาษา Go 1.8 กำลังจะถูกปล่อยตัวเต็ม ๆ ออกมาในเดือนหน้า ตอนนี้อยู่ในสถานะ beta 2 ซึ่งมี feature ที่น่าสนใจมากมาย ตัวอย่างเช่น เรามาลองใช้งาน feature ใหม่ ๆ กันหน่อย ปล. สามารถดูรายละเอียดเพิ่มเติมได้ที่ Go 1.8 Release Notes

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

[code] $go get golang.org/x/build/version/go1.8beta2 [/code] เมื่อติดตั้งด้วยคำสั่ง [code] $go1.8beta2 download [/code] เพียงเท่านี้ก็ใช้งานได้แล้ว

มาดูอย่างแรกก็คือ Default GOPATH

โดยจะมีค่า default มาให้
  • Unix อยู่ที่ $HOME/go
  • Windows อยู่ที่ %USERPROFILE%/go
ตัวอย่างผมใช้ MacOS จะแสดงอยู่ที่ $HOME/go แสดงดังนี้ [gist id="a15e2fbd8bf88a102719784f07247968" file="2.txt"] ซึ่งทำให้เราสามารถติดตั้งพวก command line package ได้ง่าย ๆ เหมือนกับ npm ได้เลย เช่น [code] $npm install -g hello $hello [/code] เมื่อผ่าน Go จะทำอย่างไร ? [code] $unset GOPATH $go1.8beta2 get github.com/golang/example/hello $~/go/bin/hello [/code] แสดงผลการทำงานดังนี้ Hello, Go examples!

ต่อมาลองใช้งาน plugin กันหน่อย ใช้ได้เฉพาะบน Linux เท่านั้นนะ

ตัวอย่างเป็นการสร้าง plugin สำหรับการบวกเลขจำนวนเต็ม 2 ค่า สามารถเขียน plugin ชื่อว่า add_plugin.go ได้ดังนี้ [gist id="a15e2fbd8bf88a102719784f07247968" file="add_plugin.go"] จากนั้นทำการ build plugin ด้วยคำสั่ง [code] $go1.8beta2 build -buildmode=plugin add_plugin.go [/code] ผลที่ได้คือไฟล์ add_plugin.so ปล. อย่าลืม import “C” นะ เดี๋ยวจะ error ตอนใช้งานแบบนี้ [gist id="a15e2fbd8bf88a102719784f07247968" file="error.txt"] จากนั้นสร้างไฟล์สำหรับใช้งาน add_plugin ดังนี้ [gist id="a15e2fbd8bf88a102719784f07247968" file="main.go"] มีขั้นตอนการทำงานดังนี้
  • ทำการ load plugin หรือ share library ที่สร้างไว้นั่นคือไฟล์ add_plugin.so
  • ทำการ lookup หรือหา function/variable ชื่อว่า Add
  • ทำการเรียกใช้งาน function Add จาก plugin
ทำการ run จะได้ผลคือ 3 นั่นเอง และยังมี feature อื่น ๆ ที่น่าสนใจ ลองไปดูกันครับ สนุกสนานมาก ๆ

สุดท้ายแล้วมีใครใช้ภาษา Go ในการพัฒนาระบบงานบ้าง ?

ดูคำตอบได้ที่นี่ Wiki:: Go Users มีรายชื่อบริษัทในประเทศไทยด้วยนะครับ
↧
↧

ทำการสร้าง Document ของ Swift project ด้วย Jazzy

January 10, 2017, 8:41 pm
$
0
0

เห็นในกลุ่ม iOS Developer Thailand มีการสอบถามเรื่อง การสร้าง document แบบอัตโนมัติจาก comment ใน code หรือไม่ ? ซึ่งเป็นสิ่งที่ทาง Apple ลืมมั้ง !! ว่าต้องทำอย่างไร แต่มีคนทำเครื่องมือมาช่วยหลายตัว ยกตัวอย่างเช่น Jazzy สร้างโดยทีมพัฒนาของ Realm ซึ่งใช้งานมาก ๆ ดังนี้

ขั้นตอนที่ 1 เขียน comment ใน code ซะ

[gist id="09cbc3e8c2e1adbb11e50a4173f1e6b8" file="Hello.swift"]

ขั้นตอนที่ 2 ทำการติดตั้ง Jazzy

[code] $gem install jazzy [/code]

ขั้นตอนที่ 3 ทำการสร้างเอกสารด้วย jazzy

[code] $jazzy [/code] ผลที่ได้คือ สร้างเอกสารไว้ใน folder docs เอกสารออกมาหน้าตาแบบนี้ ปัญหาที่เห็นคือ private method/function ไม่มีในเอกสาร !! ดังนั้นถ้าต้องการสามารถเปลี่ยนแปลงคำสั่งดังนี้ [code] jazzy --min-acl private [/code] จะได้เอกสารสร้างดังนี้

คำถามต่อมา อยากเปลี่ยน them ได้ไหม ?

โดยค่า default จะเป็น theme app แต่ jazzy ก็มี them ให้ใช้อีกตัวคือ fullwidth สามารถเปลี่ยน them ด้วยคำสั่ง [code] jazzy --min-acl private --theme fullwidth [/code] ได้เอกสารหน้าตาแบบนี้
ตัวอย่างของ source code อยู่ที่ Github เพียงเท่านี้ก็ได้เอกสารแบบสวยๆ แล้วนะครับ
↧

Docker :: แก้ไขปัญหาของ service ใน container ยังไม่พร้อมใช้งาน

January 11, 2017, 1:36 am
$
0
0

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

เมื่อนำ Docker มาใช้งานร่วมกับระบบ Continuous Integration (CI) คือ ในแต่ละ container จะต้อง start service ต่าง ๆ ขึ้นมา ซึ่งพบว่าแต่ละ service ก็มีความช้าและเร็วในการ start service ดังนั้นถ้าต้องการทดสอบระบบที่ต้องใช้ service เหล่านี้ จะไม่สามารถทดสอบได้ หรือการทดสอบพังแน่นอน เนื่องจาก service ยัง start ไม่เสร็จนั่นเอง

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

สร้าง shell script สำหรับตรวจสอบ service ว่า start สำเร็จหรือไม่ ซึ่งจะทำการวน loop ตรวจสอบไปเรื่อย ๆ ดังนี้ [gist id="8105f3c0c99b070382beca2b78eebe27" file="waiting.sh"] ถ้าใช้ผ่าน docker compose ก็ใช้ไม่ยาก สามารถเขียนได้แบบนี้ [gist id="8105f3c0c99b070382beca2b78eebe27" file="compose"] เพียงเท่านี้ก็สามารถแก้ไขปัญหาที่พบเจอได้เรียบร้อย Reference Websites https://8thlight.com/blog/dariusz-pasciak/2016/10/17/docker-compose-wait-for-dependencies.html https://github.com/dadarek/docker-wait-for-dependencies
↧
Search

ทำไมต้องใช้ Lazy Loading ใน Data Model ด้วยนะ ?

January 12, 2017, 3:21 am
$
0
0

หลังจากที่พูดคุยเรื่อง ORM (Object Relation Mapping) ก็พบว่ามักจะพูดคุยเรื่องปัญหาของ dependency graph ที่เกิดขึ้น ซึ่งส่วนใหญ่มักจะประสบภัยกับเรื่องนี้อย่างมาก เมื่อระบบเริ่มมี model หรือ entity และความสัมพันธ์มากขึ้น สุดท้ายส่งผลให้ระบบพังสิครับ หรือไม่เช่นนั้นก็ memory หมด (OutOfMemory) ทำไมถึงเป็นเช่นนั้นนะ ? ปล. Lazy loading ยังเป็น feature ในเรื่อง ๆ อื่น ๆ อีกนะ

วิธีการที่ใช้แก้ไขปัญหาก็มีหลายแนวทาง เช่น

  • ไม่ต้องมี relation ในระดับ model ทำการ mapping model กับ table/entity กันแบบ 1 ต่อ 1 เลย
  • ถ้ายังไม่ใช้ก็ไม่ต้องไป load มาสิ ค่อยไป load เมื่อต้องการใช้งาน (Lazy loading)
  • เพิ่ม memory สิ เรารวย
  • เลิกใช้เลย

มาว่ากันเรื่องของ Lazy loading กันดีกว่า

ไปเจอบทความเรื่องที่น่าสนใจคือ Lazy loading is a code smell ทำการอธิบายไว้อย่างน่าสนใจ ว่า Lazy loading มันคือ code smell รูปแบบหนึ่ง model/entity class นั้น ๆ ต้องมีปัญหาแน่นอน เพราะว่ามีทั้งสิ่งที่ต้อง load เพื่อใช้งาน และมีสิ่งที่อาจจะไม่ต้องใช้งาน รวมกันอยู่ใน model class เดียวกัน
นั่นคือ เรากำลังออกแบบผิดหรือไม่ model เราผิดหรือไม่ ? กรอบหรือขอบเขตการทำงานผิดหรือไม่ ? model แต่ละตัวควรมีรูปแบบหรือโครงสร้างตามการใช้งานหรือไม่ ?
มาดูตัวอย่างกัน [gist id="a5d88bc87fcc45f72899a9a1600e7510" file="User.java"] คำอธิบาย ใน class User นั้นมีสิ่งที่ต้อง load อย่างเดียวคือ Name ส่วน Role และ Subscription เป็น optional นั่นคือมีหรือไม่มีข้อมูลก็ได้ แล้วจะมีไปทำไม ? คำถามที่เกิดขึ้นมาคือ ทำไมเราถึงออกแบบ model class แบบนี้ ? ทั้ง ๆ ที่ User นั้นถูกใช้งานที่แตกต่างกัน สิ่งที่เราต้องหาคำตอบให้ได้คือ
  • User จะมี Role เมื่อใด ?
  • User จะมี Subscription เมื่อใด ?
  • User จะมีเฉพาะ Name เมื่อใด ?
ถ้าตอบได้เราจึงทำการออกแบบหรือสร้าง model class ตามการใช้งาน จากบทความอธิบายไว้ว่า
  • User จะมี Role เมื่อผ่านการ authentication และ authorization มาแล้ว
  • User จะมี Subscription ได้ เมื่อมีข้อมูล report
  • User จะมีเฉพาะ Name คือ User ที่ใช้ทั่วไปในระบบ
เมื่อได้คำตอบแล้วจึงทำการสร้าง class ต่าง ๆ ได้ดังนี้ [gist id="a5d88bc87fcc45f72899a9a1600e7510" file="FinalUser.java"] ข้อดีของแนวคิดนี้คือ แต่ละ class อธิบายตัวมันเองชัดเจน (Descriptive) และมีเป้าหมายที่เฉพาะเจาะจง ทำให้การใช้งานง่ายและสะดวกขึ้น แต่ผลเสียคือมี class จำนวนมากขึ้น ซึ่งจะมองเป็นข้อดีหรือข้อเสียก็ได้ ขึ้นอยู่กับมุมมองและประสบการณ์ที่ผ่านมา รวมทั้งจำเป็นต้องเข้าใจการทำงานและใช้งานด้วยนะ ซึ่งจำเป็นมาก ๆ เมื่อระบบเริ่มมีขนาดใหญ่ขึ้น
คำถามที่น่าสนใจคือ เราทำการออกแบบ model กันอย่างไร ?
↧

สรุปเครื่องมือที่ใช้บ่อย ๆ ในการพัฒนา Software

January 15, 2017, 8:14 pm
$
0
0

ในการพัฒนา software นั้นมีเครื่องมือมากมายให้เลือกใช้งาน ต่างมีข้อดีและข้อเสียกันไป เพื่อช่วยเพิ่ม efficiency และ productivity ของตัวเองและทีม ดังนั้นจึงลองสรุปเครื่องมือที่ผมใช้งานเป็นประจำทุกวันไว้นิดหน่อย ซึ่งอาจจะประโยชน์ต่อคนอื่นบ้างก็ได้ ปล. ใครมีเครื่องมือที่น่าสนใจแนะนำกันได้นะครับ

1. Terminal

คือ command line นั่นเอง ใช้สำหรับ execute process ต่าง ๆ ซึ่งสัมพันธ์กับงานที่พัฒนาด้วย ว่าจะใช้บ่อย หรือมากน้อยเพียงใด แต่ก็ต้องใช้เป็นประจำทุก ๆ วัน ตัวอย่างการใช้งานที่เร็ว ๆ มาก คือ การ copy/move/delete ไฟล์ การ download program/app สิ่งทุกสิ่งที่ทำงานผ่าน command line ได้ ปล. สำหรับคนที่ใช้งาน terminal น่าจะต้องใช้ Tmux ด้วยนะ

2. Docker

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

3. IntelliJ IDE

เป็น IDE (Integrated Development Environment) ที่ใช้งานเป็นประจำ ไม่ว่าจะภาษาโปรแกรมอะไรก็ใช้งาน IntelliJ IDE เป็นหลัก เนื่องจากมี feature ต่าง ๆ ที่ช่วยทำให้การพัฒนาเร็วและง่ายขึ้น ทั้ง Auto-completion, UI ที่ใช้ง่าย รวมไปถึง Error analysis และ Quick fix ให้ใช้งาน จากการใช้งานมาพบว่า เพิ่ม productivity อย่างมาก

4. Slack

เป็น app เอาไว้ใช้ติดต่อสื่อสาร พูดคุย และ sync yp กันภายในทีม เพื่อลดการใช้งาน email กันภายในทีม สามารถแบ่งกลุ่มหรือ channel ของการพูดคุย มี direct message ให้คุยตรง ๆ กันได้ รวมทั้งยังสามารถ integrate เข้ากับระบบต่าง ๆ ได้ง่ายอีกด้วย เช่น integrate เข้ากับระบบ Continuous Integration, Continuos Delivery เมื่อเกิดปัญหาก็ให้แจ้งไปยังคนหรือกลุ่มที่เกี่ยวข้อง รวมทั้งสามารถพัฒนา bot ไว้ใช้งานได้อีกด้วย ปล. ถ้าเสียเงินให้ slack จะดีกว่านี้ แต่เท่าที่ใช้งานแบบฟรีก็แจ่มแล้วนะ !!

5. Feedly

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

6. Git และ Github

Git เป็น distributed version control สำหรับการจัดการ source code หรือเอกสารของระบบงาน เพื่อทำการบันทึกการเปลี่ยนแปลงต่าง ๆ ไว้ ทำให้การทำงานเป็นทีมง่ายและสะดวกขึ้น ส่วน Github คือระบบ web สำหรับให้บริการ Git repository เราสามารถ push/pull code ได้ เราสามารถ upload/download ได้ เราสามารถค้นหาสิ่งที่ต้องการได้ สามารถเลือกใช้ได้ทั้งปรีและเสียเงิน หลาย ๆ บริษัทใช้ Github เป็นอีกช่องทางหนึ่งในการรับพนักงานด้วยนะ !! ถ้าต้องการติดตั้งเป็น server ของตัวเองสามารถใช้ Gitlab ได้ ปล. ใครบ้างที่ยังไม่ใช้ version control บ้างนะ ?

7. Sublime และ Atom

เป็น Text Editor ที่ใช้งานเป็นประจำ บางคนอาจจะบอกว่าทั้งสองต่างกันหรือดีกว่ากันอย่างไร แต่ผมก็ใช้ทั้งสองนั่นแหละ เนื่องจากโดยพื้นฐานจะไม่ต่างกันมาก ทั้ง shortcut key และระบบ plugin

8. Google Chrome

เป็น browser ที่ใช้บ่อยที่สุดแล้ว เนื่องจากมันใช้งานง่าย เร็ว แถมมี extension และ developer tool ให้ใช้แบบครบครัน ปล. กิน RAM น่าดู !!

9. Jenkins

สำหรับการสร้างระบบ Continuous Integration (CI) ของการพัฒนาระบบงานต่าง ๆ แล้ว จะเลือกใช้งาน Jenkins เป็นตัวแรก ช่วยให้เราสามารถสร้างระบบ build automation ของระบบได้ง่าย ดังนั้นเมื่อมีการเปลี่ยนแปลงเกิดขึ้นมา ระบบ Jenkins จะทำการ build แบบอัตโนมัติให้ เป็นสิ่งที่สำคัญมาก ๆ ต่อการพัฒนา software ถ้าเป็นระบบ Cloud จะใช้งานผ่าน Travis-CI

10. StackOverflow.com

สำหรับนักพัฒนาแล้ว StackOverflow คือคัมภีร์เปลี่ยนเส้นเอ็นเลยก็ว่าได้ เนื่องจากมีทุกคำตอบจากทุกคำถาม เพราะว่า ถ้าไปค้นหาจาก google ก็จะพบคำตอบแรก ๆ จากที่นี่ทั้งนั้น ดังนั้นนักพัฒนาต้องหัดใช้ให้เป็นนะครับ แล้วจะเพิ่ม productivity อย่างมาก ปล. อย่า copy คำถามมาใช้นะครับ !!
สุดท้ายก็ Youtube เอาไว้เปิดเพลงฟัง
↧
↧

การทำ Stress testing สำหรับ Android app

January 17, 2017, 8:43 pm
$
0
0

ในการพัฒนา Android app นั้นการทดสอบนั้นสำคัญมาก ๆ ทั้ง Developer testing คือ การทดสอบในมุมมองของนักพัฒนา ทั้ง Customer testing คือ การทดสอบในมุมมองของลูกค้าหรือผู้ใช้งาน แต่สิ่งหนึ่งที่มักจะละเลยไปมากคือ Stress Testing ดังนั้นมาสรุปกันหน่อยว่าต้องทำอะไรบ้าง ?

เริ่มด้วย Android Monkey Testing

สำหรับจำลอง event ต่าง ๆ ขึ้นมาแบบ random ซึ่งสามารถใช้งานผ่าน command-line ได้ดังนี้ [code] $adb shell monkey -p YOUR_PACKAGE_NAME [/code]

เรื่องที่ 2 คือความเร็วและช้าของ Network ที่ใช้งาน

ในการกำหนดความเร็วความช้าของระบบ Network นั้น สามารถกำหนดผ่าน emulator ได้ง่าย ๆ เลย เพราะว่ามี feature นี้อยู่แล้ว แต่ถ้าต้องการทดสอบผ่าน device จริง ๆ การจำลองระบบ network มันก็ยากพอสมควร ดังนั้นสิ่งที่แนะนำก็คือ Debug Drawer ซึ่งสามารถกำหนดความเร็วของระบบ Network ใน App ของเราได้เลย ตัวอย่างเช่น แสดงการใช้งานดังรูป

เรื่องที่ 3 App จัดการกับ Error ต่าง ๆ ได้หรือไม่ ?

ตัวอย่างเช่นถ้ามี error ส่งกลับมาจาก HTTP แล้ว App ของเราสามารถจัดการหรือรับมือได้หรือไม่ ? เพื่อดูว่า error ที่เกิดขึ้นมา ถูกส่งไปยังระบบของเราหรือไม่ ? ตัวอย่างการกำหนด Error rate ผ่าน Debug Drawer

เรื่องที่ 4 การทำงานใน Offline mode

ตัวอย่างเช่นการปิดระบบ network และเปิด airplane mode เป็นต้น เป้าหมายที่เราต้องการคือ
  • App crash หรือไม่ ?
  • ทำการแสดงข้อความต่าง ๆ ให้ผู้ใช้งานหรือไม่ ?
  • Caching data ถูกจัดเก็บได้อย่างถูกต้องหรือไม่ ?
  • เมื่อกลับมาทำงานแบบ Online mode แล้ว App สามารถทำงานได้อย่างถูกต้องหรือไม่ ? เช่น clear cache หรือส่ง caching data ไปยังระบบกลาง เป็นต้น

เรื่องที่ 5 ทำการ Update app ดูบ้างสิ

ถ้า App มีการเก็บข้อมูลต่าง ๆ ไว้ทั้งใน device และ server แล้ว เช่น
  • การเปลี่ยนแปลงที่ SharedPreference
  • การเปลี่ยนแปลงที่ Database
  • การเปลี่ยนแปลงที่ API
สิ่งที่ต้องทำคือ ถ้าทำการ update app แล้ว ข้อมูลต่าง ๆ เหล่านั้นยังคงอยู่ ไม่ถูกลบไป และผู้ใช้งานสามารถใช้งาน App ต่อไปได้

เรื่องที่ 6 ทำการลบ App หรือ clear memory/data ใน background mode ดูสิ

App ส่วนมากมักจะทำการเก็บข้อมูล หรือ ทำงานหลายอย่างใน background mode ดังนั้นบางครั้งถ้าเราไปลบข้อมูลของ App ในขณะที่อยู่ใน background mode แล้วทำการเปิด App ขึ้นมาใช้ อาจจะทำให้ App crash ได้ เนื่องจากไม่ทำการตรวจสอบข้อมูลและ re-ininitial ข้อมูลใหม่ขึ้นมา ดังนั้นสามารถทดสอบได้ง่าย ๆ เช่น เข้าไป clear data/memory usage ใน device หรือทำการลบผ่าน command line ดังนี้ [code] $adb shell am kill YOUR_PACKAGE_NAME [/code] หรือเข้าไปกำหนดค่าไม่ให้ device เก็บ activity เมื่อผู้ใช้งานไม่ใช้งาน App นั้นแล้ว

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

  • การหมุนหน้าจอ (Orientiaion)
  • Multi-window mode และ TransactionTooLargeException สำหรับ Android N
  • เรื่องของการทดสอบพวก Unit testing, Integration testing, API testing และ UI testing ก็อย่าให้ขาดนะ !!
ขอให้สนุกกับการพัฒนา Android app ครับ Reference Websites https://android.jlelse.eu/stress-testing-android-apps-601311ebf590#.21g9b3twk
↧

มาทำแบบทดสอบเรื่อง Continuous Integration (CI) กัน

January 19, 2017, 2:54 am
$
0
0

จากบทความเรื่อง Continuous Integration Certification นั้น มีแบบทดสอบการใช้งาน CI ที่น่าสนใจ ดังนั้นลองมาทำแบบทดสอบกันหน่อย เริ่มได้เลย ข้อที่ 1 นำ Continuous Integration มาใช้งานหรือไม่ ? ข้อที่ 2 ทุกคนในทีมทำการ commit และ push การเปลี่ยนแปลงต่าง ๆ ไปยัง version control กลางเป็นประจำหรือไม่ ? เช่นทำทุก ๆ วันเป็นต้น แต่ผมว่าน่าจะทุก ๆ ชั่วโมงนะ ข้อที่ 3 ในแต่ละ commit นั้นจะทำให้เกิดการ build และ test แบบอัตโนมัติหรือไม่ ? ข้อที่ 4 เมื่อผลการ build และ test มัน fail หรือไม่ผ่านแล้ว ต้องทำการแก้ไขเพื่อให้ผลการ build และ test มันกลับมาผ่าน ในระยะเวลาไม่เกิน 10 นาที หรือไม่ ?
ถ้าใครก็ตามตอบใช่ ทั้ง 4 คำถาม แสดงว่าคุณผ่านการทดสอบแล้วนะ !!!
↧

สวัสดี Docker 1.13.0 กันเล็กน้อย

January 22, 2017, 3:35 am
$
0
0

Docker

หลังจากที่ Docker 1.13.0 ถูกปล่อยออกมา มี feature ใหม่เพิ่มเข้ามามากมาย มีการปรับปรุงมากมาย มีการแก้ไข bug มากมาย มีสิ่งที่ deprecated มากมาย ดูเพิ่มเติมได้ที่ Release Note :: 1.13.0 แต่ feature ที่ส่วนตัวชอบมีดังนี้

เรื่องที่ 1 Prune command

ก่อนหน้าที่ถ้าต้องการ clear สิ่งต่าง ๆ ที่เราไม่ต้องการ หรือไม่ถูกใช้นาน ๆ ทั้ง image และ container ต้องใช้คำสั่งที่ยึดยาว เช่น [code] $docker rm -f $(docker ps -aq) $docker rmi -f $(docker images -q $docker ps -a | grep 'Exited' | awk '{print $1}' | xargs docker rm [/code] แต่ใน Docker 1.13.0 นี่ง่ายกว่ามากผ่าน Prune command ดังนี้ [code] $docker system prune [/code] ผลการทำงานเป็นดังรูป จากนั้นเอาไปใส่ใน scheduler ให้ทำงานตลอดเลย

เรื่องที่ 2 CLI ของ Docker ที่เข้าใจง่ายขึ้น

ถ้าต้องการจัดการ container ก็ใช้งาน $docker container ถ้าต้องการจัดการ system ก็ใช้งานผ่าน $docker system ถ้าต้องการจัดการ image ก็ใช้งานผ่าน $docker image ถ้าต้องการจัดการ volume ใช้งานผ่าน $docker volume

เรื่องที่ 3 เพิ่ม output ของ metric api ของ container, image และ daemon operation ในรูปแบบของ Prometheus

ทำให้สามารถส่งข้อมูลไปยัง Prometheus ง่ายเลย ดังนั้นเรื่องของ monitoring จึงง่ายและมีทางเลือกมากยิ่งขึ้น แต่ยังเป็น experiment นะครับ อาจจะเอา feature ออกไปก็ได้ สำหรับ Docker for Mac สามารถเปิด Metric api ได้ดังนี้ แก้ไขไฟล์ daemon.json ดังนี้ จากนั้นทำการ Apply และ Restart ซะ มาลองสร้าง container และดึงข้อมูลผ่าน Metric API กันดังนี้ [code] $docker run --rm --network=host alpine sh -c 'apk add --no-cache -q curl && curl localhost:1337/metrics' [/code] ผลที่ได้เป็นดังนี้ Reference Websites https://blog.docker.com/2017/01/whats-new-in-docker-1-13/ https://blog.codeship.com/whats-new-docker-1-13/ https://codefresh.io/blog/everyday-hacks-docker/
↧
Viewing all 2000 articles
Browse latest View live
Search