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

Part 1 :: เริ่มต้นเรียนรู้ไปกับ React.js app

$
0
0

react-00

react-00 หลังจากไปงาน Thailand React Meetup มารู้สึกว่าน่าสนใจ เลยลองมาหัดเขียน หัดเรียนรู้ และ หัดเขียน React กันหน่อย ด้วยการลงมือสร้าง app แบบง่าย ๆ แน่นอนว่า ต้องมี Hello World และ App อื่น ๆ ที่ช่วยทำให้เราเข้าใจ React มากยิ่งขึ้น มาเริ่มกันเลย

เริ่มต้นจากมาออกแบบ web ที่เราต้องการสร้างกันดีกว่า (หัวใจของการพัฒนา)

ต้องการสร้าง web portfolio ง่าย ๆ ประกอบไปด้วย 2 ส่วนหลัก คือ
  1. Profile
  2. List ของ project
แสดงดังรูป react-01

ทำการแบ่งการทำงานในแต่ละส่วนเป็น component

เนื่องจาก React app นั้นจะประกอบไปด้วย component ต่าง ๆ ทำงานร่วมกัน ซึ่งก่อนที่จะลงมือเขียน code นั้น แนะนำให้ออกแบบดี ๆ ก่อนเสมอนะ จากตัวอย่างใน App ประกอบไปด้วย 2 component ย่อย คือ
  1. Profile component
  2. Projects component
แสงดังรูป react-02 ปล. เราสามารถแยกออกเป็น component ย่อย ๆ ไปได้อีกนะ แต่เราเพิ่งศึกษาก็อย่าเยอะ !!

เริ่มต้นด้วยการสร้าง Hello World app

เพื่อทำความรู้จัก และ เข้าใจ การใช้งาน library ต่าง ๆ การสร้าง React component [gist id="b555a4cb8a8f67adc78d41ed3ef60030" file="step_01.html"] จากนั้นทำการสร้าง component แรกกันเลย ดังนี้ [gist id="b555a4cb8a8f67adc78d41ed3ef60030" file="step_02.html"] คำอธิบาย สร้าง component ผ่าน method createClass() ของ class React โดยสามารถทำการส่ง parameter ได้ 1 ตัวเรียกว่า specification object คือ object ที่สามารถมี method ใด ๆ ก็ได้ตามที่เราต้องการ โดยหนึ่งใน method ที่สำคัญคือ render() เพื่อทำการแสดงข้อมูลที่ต้องการออกมา จากตัวอย่างคือ tag div มีข้อมูลว่า Hello World

จากนั้นต้องสั่งให้ทำการแสดงผลจาก App component ผ่าน ReactDOM

ซึ่งเราสามารถส่ง paramater ตัวแรกคือ App component ส่วนตัวที่สองคือ element ที่เราต้องการให้แสดง เมื่อทุกอย่างเรียบร้อยลอง run ผ่าน browser ได้เลย จะแสดงคำว่า Hello World ที่หน้าจอ

มาทำการสร้าง Component อื่น ๆ กันดีกว่า

โดยเราจะทำการสร้าง Profile และ Projects component ดังนี้ [gist id="b555a4cb8a8f67adc78d41ed3ef60030" file="step_03.html"] จากนั้นทำการเพิ่มทั้งสอง component เข้าไปยัง App component หรือ component หลักของเรา ดังนี้ [gist id="b555a4cb8a8f67adc78d41ed3ef60030" file="step_04.html"] ผลการทำงานเป็นดังนี้ react-03 มาถึงตรงนี้ ทำให้เราเข้าใจเรื่องของ component มากยิ่งขึ้น ซึ่งพบว่าเราสามารถแบ่งงานใหญ่ออกเป็นงานย่อย ๆ ได้ง่าย นั่นทำให้เราสามารถจัดการระบบได้ง่ายขึ้น (ถ้าออกแบบดีนะ)

ในตอนนี้ส่วนของ Projects component นั้นเรายัง dummy ข้อมูลกันอยู่

ดังนั้นสิ่งที่เราต้องการต่อไปก็คือ ส่งข้อมูล project เข้าไปยัง component แทน โดยที่ React มี data flow หรือการส่งข้อมูลแบบ One direction data flow นั่นหมายความว่าจะส่งข้อมูลจาก Parent component ไปยัง Child component เสมอ และส่งต่อไปยัง Child component ต่อ ๆ ไป ทำให้ง่ายต่อการจัดการ แต่ถ้าออกแบบไม่ดีแล้ว จะทำให้การจัดการยากขึ้นนะ !! แสดงดังรูป react-04 จากตัวอย่างก็คือ สามารถส่งข้อมูลเข้าไปยัง Profile และ Projects component ผ่าน App นั่นเอง ดังนั้นในแต่ละ component ของ React มันคือ function ที่รับข้อมูลผ่าน
  • Props object ?
  • State ? (เอาไว้ก่อน เดี๋ยวยาว)
จากนั้นทำการส่งผลลัพธ์ที่เป็น HTML ออกมา

มาถึงตรงนี้ก็สงสัยว่า props มันคืออะไร ?

มันคือ object หนึ่งที่ทำการเก็บข้อมูลในรูปแบบต่าง ๆ เช่น Array, Object, ตัวเลข และ function เป็นต้น
โดยเป็น immutable object แสดงว่า ไม่สามารถแก้ไขข้อมูลได้ และใช้สำหรับ share ข้อมูลให้กับ component อื่น ๆ
ถ้าทำการเปรียบเทียบกับ tag ของ HTML แล้ว Component คือ tag Props คือ attribute นั่นเอง ตัวอย่างเช่น [code] <Test className=’test.jpg’ onClick={handleClick} /> [/code] คำอธิบาย
  • Component ชื่อ Test
  • className และ onClick คือ props

ดังนั้นกลับมาที่ App ถ้าต้องการส่งข้อมูลไปยัง Profile component จะทำอย่างไร ?

ทำการส่งข้อมูลจาก App component ด้วยชื่อ profileData [gist id="b555a4cb8a8f67adc78d41ed3ef60030" file="step_05.html"] จากนั้นใน Profile component ทำการดึงข้อมูลผ่าน props object ดังนี้ [gist id="b555a4cb8a8f67adc78d41ed3ef60030" file="step_06.html"] เท่านี้ก็สามารถส่งข้อมูลเข้ามายัง Profile component ได้แล้ว

ลองมาส่งข้อมูล list ของ project เข้าไปยัง Projects component กันต่อ

โดยข้อมูลที่จะส่งเข้าไปเป็น array และให้ส่งจาก App component เข้าไปเหมือนเดิม [gist id="b555a4cb8a8f67adc78d41ed3ef60030" file="step_07.html"] จากนั้นสิ่งที่เราต้องคิดก่อนก็คือ ใน Projects component นั้นจะต้องทำการวน loop เพื่อแสดงข้อมูลของแต่ละ project ซึ่งประกอบไปด้วย รูป และ ชื่อของ project ดังนั้นสิ่งที่ควรจะต้องสร้างเพิ่มคือ ProjectItem ไว้สำหรับจัดการในแต่ละ project นั่นเอง โดยวิธีการจะทำตามคำแนะนำของ React :: Multiple component :: Dynamic children ซึ่งได้ code ดังนี้ [gist id="b555a4cb8a8f67adc78d41ed3ef60030" file="step_08.html"] ดังนั้นรวมทุกอย่างเข้าด้วยกัน เป็นดังนี้ [gist id="b555a4cb8a8f67adc78d41ed3ef60030" file="step_09.html"]

เพียงเท่านี้เราก็สามารถสร้าง React app แรกแบบง่าย ๆ ได้แล้ว

ซึ่งมีเป้าหมายเพื่อ
  • การออกแบบ component ซึ่งมีความสำคัญอย่างมาก
  • ทำความเข้าใจเกี่ยวกับ React component
  • ทำความเข้าใจเกี่ยวกับการส่งข้อมูลระหว่าง component (Data flow)
แต่ยังมีอีกมากมายหลายเรื่องให้เราศึกษา !! โดย code ตัวอย่างอยู่ที่ Github::Up1:React

Part 2 :: มาทดสอบการสร้าง React component ด้วย Storybook กัน

$
0
0

storybook-00

storybook-00 จาก blog เรื่อง Part 1 :: เริ่มต้นเรียนรู้ไปกับ React นั้น มีคำถามต่าง ๆ เกิดขึ้นมาคือ เมื่อเราทำการออกแบบ และ สร้าง Component ต่าง ๆ ขึ้นมาแล้ว จะรู้ได้อย่างไรว่า
  • สิ่งที่เราออกแบบมันดีพอ ?
  • สิ่งที่เราออกแบบมันใช้งานง่ายหรือไม่ ?
  • สิ่งที่เราอออกแบบมันทดสอบได้ง่ายหรือไม่ ?
  • สิ่งที่เราออกแบบทำงานได้อย่างถูกต้องในกรณีต่าง ๆ หรือไม่ ?
  • จะทดสอบและตรวจสอบการทำงานในแต่ละ component อย่างไร ?
วันนี้น้องในทีมได้แนะนำ Storybook ซึ่งมันสามารถตอบโจทย์ต่าง ๆ ได้ดีพอสมควร จึงทำการทดลอง และ สรุปการใช้งานไว้นิดหน่อย

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

[code] $npm i -g getstorybook [/code] เพื่อความง่ายจึงทำการแปลง project จากตัวอย่างใน Part 1 :: Hello React มาอยู่ในรูปแบบ project ที่สร้างด้วย Create React App โดย code ตัวอย่างสำหรับ blog นี้อยู่ที่ Github::React with storybook แล้วเริ่มใช้งาน Storybook ด้วยคำสั่ง [code] $getstorybook [/code] ผลที่เกิดขึ้นคือ ทำการสร้างไฟล์ configuration ของ Storybook ซึ่งอยู่ใน folder .storybook จากนั้นทำการ run Storybook ด้วยคำสั่ง [code] $npm run storybook [/code] สามารถเข้าใช้งานผ่าน browser ด้วย url=http://localhost:9001 แสดงดังรูป storybook-01 แถมยังมี keyboard shortcut ให้ใช้งานอีกด้วย storybook-02

จากนั้นจึงเริ่มสร้าง story ต่าง ๆ ใน Storybook

เพื่อใช้สร้าง story ของแต่ละ component นั่นเอง โดยสามารถกำหนด path ของ story ต่าง ๆ ในไฟล์ .storybook/config.js ในตัวอย่างจะเก็บไว้ใน folder /src/stories ซึ่งสามารถเพิ่มได้เรื่อย ๆ นะ ดังนี้ [gist id="bc3c82d5b259599309d10ee82426f770" file="config.js"]

เมื่อจัดการเรียบร้อยก็ถึงเวลาสร้าง Story ของแต่ละ component กัน

เริ่มด้วยการสร้าง story สำหรับ Profile component ซึ่งจะส่งข้อมูล Hello ผ่าน props เข้ามา [gist id="bc3c82d5b259599309d10ee82426f770" file="index01.js"] แสดงผลการทำงานดังรูป storybook-03
จะเห็นได้ว่าเราสามารถส่งข้อมูล เปลี่ยน state ต่าง ๆ จากนั้นดูว่า แต่ละ component ทำงานตรงตามที่เราต้องการหรือไม่ ? แถมทำให้เรารู้ได้ทันทีว่า component ที่สร้างนั้นมันทดสอบได้ยากหรือไม่ ? หรืออาจจะทำให้รู้ว่า เราออกแบบผิดได้อย่างรวดเร็ว

จากนั้นเขียน Story ของ component อื่น ๆ ด้วย ดังนี้

[gist id="bc3c82d5b259599309d10ee82426f770" file="index02.js"] แสดงผลการทำงานดังรูป storybook-04

สุดท้ายแล้วจากการรู้จัก Storybook เพียงเล็กน้อย

คิดว่ามันน่าจะช่วยทำให้การพัฒนาระบบด้วย React สนุกขึ้นอย่างมาก แถมยังมีความสามารถอีกเยอะเลยเช่น Addon ทำให้การใช้งานสนุกและสะดวกสบายมากขึ้น ลองเข้าไปดูเพิ่มเติมได้ที่ Storybook documentation ปล. เทคนิดสำหรับการออกแบบ Component คือการมองจากภาพใหญ่ลงไปยังส่วนเล็ก ๆ แต่สำหรับการสร้าง component จะสร้างจาก component ที่เล็กที่สุดออกมา เนื่องจากมี dependency น้อยที่สุด และ สร้างได้ง่ายที่สุด

[Android] ลดขนาดของไฟล์ APK ด้วยการลบสิ่งที่ไม่ใช้งานออกไปบ้าง

$
0
0

android-lint-00

android-lint-00 เมื่อเราทำการพัฒนา Android app ไปเรื่อย ๆ สิ่งที่เกิดขึ้นมาอย่างมากคือ Resource ต่าง ๆ ที่เราไม่ใช้งานเยอะมาก ๆ ซึ่งอยู่ใน folder res และ code ของเราตลอดจน library !! ส่งผลให้ขนาดของไฟล์ APK มีขนาดใหญ่จนเกินไป ดังนั้น สิ่งที่นักพัฒนาควรทำคือ ลบสิ่งที่ไม่ถูกใช้งานออกไปบ้าง มาลบกันดีกว่า

เริ่มด้วยวิเคราะห์ก่อนว่ามี resource อะไรบ้างที่ไม่ถูกใช้งาน

ใน Android studio นั้นมีเครื่องมือให้พร้อมเลย เช่น
  • Analyze -> Inspect code
  • Analyze -> Code cleanup
  • Refactor -> Remove unused resources
ปล. แต่นักพัฒนาไม่ค่อยรู้จักหรือใช้งานกันหรือเปล่านะ ? หรือสามารถใช้งาน Android Lint  ได้อีกด้วย ด้วยคำสั่ง [code] $./gradlew clean lint [/code] จะทำการแสดงผลลัพธ์ไว้ที่ build/output/lint-results-devDebug.html และ xml แสดงดังรูป android-lint-03

จากนั้นให้ลองทำการสร้างไฟล์ apk ก่อนการลบ resource

เพื่อวิเคราะห์ไฟล์ APK ด้วย Build -> Analyze APK ซึ่งจากตัวอย่างนั้นไฟล์ APK มีขนาด 7.5 MB ในตอนนี้เรารู้ค่าเริ่มต้นก่อนทำการแก้ไขแล้วนะ แสดงดังรูป android-lint-04

ต่อมาจึงทำการลบ resource ต่าง ๆ ที่ไม่ใช้งานด้วย Refactor -> Remove unused resource

ดังรูป android-lint-02 โดยผลลัพธ์ที่ได้มันน่าประทับในอย่างมาก เนื่องจากขนาดของไฟล์ APK ลดจาก 7.5 MB เหลือเพียง 6 MB แสดงดังรูป android-lint-05

ยังไม่พอนะครับ ยังมีเครื่องมืออื่น ๆ ให้ใช้งานอีก

เช่น Android Resource Remover จาก KeepSafe เป็นเครื่องมือสำหรับการลบ resource ที่ไม่ได้ใช้งานจากผลการทำงานของ Android Lint นั่นเอง ลองติดตั้งและใช้งานดูครับ
สุดท้ายแล้ว นักพัฒนาที่ดีต้องหัดลบสิ่งที่ไม่ใช้งานหรือจำเป็นออกไปบ้างนะ
ปล. สุดท้ายก่อนจบ ในส่วนการ release อย่าลืมทำแบบนี้นะ [gist id="fa4f06654e0e4ea5397a013c62a0e4fc" file="build.gradle"]

ยังไม่พอนะ สำหรับการลดขนาดไฟล์ APK

มีคำแนะนำเพิ่มเติมดังนี้
  • ใช้งาน Proguard ให้คุ้มกันหน่อย
  • ใช้งาน Vector drawable
  • Apk split
  • อย่าลืม optimize png image
  • พยายามใช้งาน 9-patch image
  • ลดขนาดของไฟล์ JPG ด้วย
  • ลบการ debug ใน code ออกไป
  • ลด duplicate ของ code
  • ให้ใช้ Android Lint กันเป็นหลัก
  • พยายาม reuse resource ต่าง ๆ ให้ได้มากขึ้น
  • ระมัดระวังพวก media format ให้มากทั้ง image, audio และ video
Reference Websites Shrink Your Code and Resources Reduce size APK

มาดูกันว่า 4 ปีที่ผ่านมาของการพัฒนา Instagram Android App เป็นอย่างไรบ้าง ?

$
0
0

instagram-00

instagram-00 เคยนำบทความต่าง ๆ ของการพัฒนาระบบ Instagram มาแปลและสรุป ในครั้งนี้เป็นเรื่องราวสำหรับการพัฒนา Android app ว่าในช่วง 4 ปีที่ผ่านมานั้น ได้ทำอะไรมาบ้าง ? ผ่านร้อนผ่านหนาวอะไรมาบ้าง ? ตั้งแต่ version แรกที่พัฒนาด้วย engineer 2 คน ใช้เวลาไป 4 เดือน จนตอนนี้ทีมมีจำนวน 30 คนแล้ว ทำการแปลและสรุปจากบทความเรื่อง Instagram + Android: Four Years Later มาไว้นิดหน่อย น่าจะเป็นประโยชน์ต่อนักพัฒนากันบ้าง ทั้งการรับมือเรื่องขยายทีม ทั้งการรับมือเรื่องการดูแลรักษาระบบ ทั้งการเพิ่มความสามารถต่าง ๆ ทั้งการดูเรื่องขนาดของ APK ทั้งการดูเรื่อง performance ที่ขึ้นชื่อว่าเร็วมาก ๆ

เริ่มต้นด้วยข้อมูลและสถิติต่าง ๆ ก่อน

  • 30 คือ จำนวนสมาชิกของทีม Android
  • 19.3 MB คือ ขนาดของ APK แบบ raw size (ใช้ข้อมูลล่าสุดวันที่ 20 กันยายน 2556)
  • 15.4 MB คือ ขนาดของ APK แบบที่ผู้ใช้งานต้อง download และ ติดตั้ง
  • ถูกติดตั้งมากกว่า 1 พันล้านครั้ง
  • 4.5 คือคะแนนของการ review บน Google Play
  • 38 ล้านคือจำนวนคน review
สิ่งที่น่าสนใจมาก ๆ คือ การดูแลรักษา value หรือคุณค่าในสิ่งที่กำลังสร้าง นั่นหมายถึง feature บน Android app มันจะต้องมีคุณค่าเพิ่มขึ้น ตามขนาดของทีมที่โตขึ้นเสมอ

จาก Core Value ของทีมพัฒนา Instagram คือ Do the Simple Thing First

โดยจะทำการสร้าง feature ที่คนใช้ต้องการใช้ หรือ ใช้อยู่แล้วก่อนเสมอ รวมทั้งให้ความสนใจในเรื่อง performance ของระบบอย่างมาก ซึ่งจะแยกส่วนการทำงานต่าง ๆ ออกจากกันอย่างชัดเจน (Component) เพื่อทำให้สามารถแก้ไขและปรับปรุงระบบได้ง่าย ตัวอย่างเช่น Android app ทำหน้าที่ render ข้อมูลที่ได้รับจาก server ทำหน้าที่เหมือน Web browser การประมวลผล business logic ที่ซับซ้อนทำงานที่ server side ทำให้ง่ายต่อการแก้ไข bug และ เพิ่ม feature ใหม่ ในฝั่ง server จะต้องทำการส่งข้อมูลที่จำเป็นต่าง ๆ ให้ครบ ดังนั้นจึงต้องมีระบบ Continuous Integration Testing เพื่อทำให้มั่นใจว่าสิ่งที่สร้างทำงานดังที่หวัง และ feature เก่า ๆ ยังคงทำงานได้เหมือนเดิม ผลที่ตามมาก็คือ ฝั่ง Android app แทบจะไม่ต้อง ทำการตรวจสอบค่าว่าเป็น Null หรือไม่ ? ทำการตรวจสอบว่าข้อมูลใช้ได้หรือไม่ ? เนื่องจาก Android app ส่วนใหญ่ที่ crash ก็มาจากเรื่องเหล่านี้แหละนะ ดังนั้นจึงทำการแก้ไขปัญหาที่ต้นเหตุกันดีกว่า ยังไม่พอนะ ยังมีระบบ Automated Crash Report ให้อีก ซึ่งจะแจ้งสาเหตุของการ crash มาให้ แน่นอนว่ามี stack trace มาให้ เพื่อช่วยทำให้การแก้ไขง่ายขึ้น จะได้ช่วยลด ละ เลิก การ debug app !!

เมื่อ Android app มีขนาดใหญ่ขึ้น

แน่นอนว่า จำนวน source code ต้องเยอะขึ้น ดังนั้นสิ่งที่ต้องดูแลรักษาอย่างหนักก็คือ
  • Source code ต้องง่ายและทำความเข้าใจได้ง่าย
  • Source code สามารถอธิบายตัวมันเองได้
  • Source code ต้อง debug ได้ง่าย
  • ทำการ generate source code ให้น้อยที่สุด
  • ลดการใช้ runtime annotation ลงไป
  • รวมทั้งลดการใช้พวก maagic library ต่าง ๆ
โดยรวมแล้วพยายามเขียน code ให้เรียบง่ายที่สุด ไม่ซ่อนความซับซ้อนไว้ข้างหลัง ในการเขียน code นั้นทีมพัฒนา Android ได้เรียนรู้ว่า ช่วงแรกของการพัฒนานั้น ทีมมีขนาดเล็ก รวมทั้งมีความกดดันที่ต้องเสร็จเร็ว ๆ ดังนั้นใน code จึงเต็มไปด้วย inheritance !! แต่เมื่อทีมมีขนาดใหญ่ขึ้นก็พบว่า แนวทางที่ทำอยู่นั้นไม่สามารถ scale ได้ตามขนาดของทีม เนื่องจาก code แต่ละส่วนผูกติดกันอย่างมาก ผลก็คือ มันยากมาก ๆ ต่อการแก้ไข และ เพิ่ม feature ใหม่ ดังนั้นแนวคิดในการพัฒนาจึงเปลี่ยนไปใช้ Composition over inhertiance ซึ่งเหมาะสมกับทีมและสิ่งที่กำลังพัฒนามากกว่า

มาดูการ Optimize App กันบ้าง !!

โดยจะทำการปรับปรุง performance ใน feature ที่มีคนใช้งานเยอะ ๆ เป็นหลัก ตัวอย่างเช่น การจัดการกับข้อมูล JSON โดยใน version ที่ 1 นั้นใช้งาน library Jackson Data Binding ซึ่งพบปัญหาว่า ทำงานช้ามาก ๆ บนมือถือกลุ่ม Low-end (เครื่องที่ CPU และ RAM น้อย ๆ) ดังนั้นจึงทำการเขียน library ขึ้นมาใช้เอง เพื่อให้ตรงกับความต้องการ สามารถอ่านเพิ่มได้ที่ Fast, auto-generated streaming JSON parsing for Android การจัดการกับ Activity Screen โดยใน version แรก ๆ นั้นจะทำการแสดง activity ต่าง ๆ เช่นการ like และ comment ผ่าน App ด้วย WebView !!! เนื่องจากทำให้ง่ายต่อการเพิ่มชนิดของข้อมูลต่าง ๆ แต่กลับพบว่า การใช้งาน WebView นั้นทำให้ App ช้าลงไป 30% ดังนั้นจึงทำการเขียน code ขึ้นมาใหม่ สามารถอ่านเพิ่มได้ที่ Building a better Instagram app for Android
จะเห็นได้ว่า ทีมพัฒนาก็ต้องมีเครื่องมือในการวิเคราะห์ข้อมูลต่าง ๆ ของ App เพื่อทำให้เห็นว่า ส่วนไหนของ App ที่มีปัญหา ทั้ง performance, startup time, data usage รวมทั้งรายงานเกี่ยวกับ bug ต่าง ๆ อีกด้วย
ปล. ลองกลับมาดู App ของเราสิว่า ยังขาดอะไรไปบ้าง ?

มาถึงเรื่อง Effienct UI สรุปสั้น ๆ ได้ว่า

เป้าหมายก็คือ สร้าง App ที่ทำงานได้อย่างรวดเร็ว และ สวยงาม แน่นอนว่า อ่านแล้วมันดูขัดแย้งกันพอสมควร ทางทีมพัฒนา App ของ Instragram สรุปไว้ดังนี้ ในช่วง Startup time ของ App ต้องน้อย ๆ ดังนั้นพวกขนาดของรูปต้องลด ทั้งขนาด ทั้ง texture ทั้ง color ที่ไม่จำเป็นออกไป รวมทั้งพวก asset ต่าง ๆ อีก รวมไปถึงเวลาในการเปิดหน้าอื่น ๆ อีกด้วย ส่งผลทำให้ขนาดของ App เล็กลงไปด้วย ซึ่งมีผลอย่างมากต่อผู้ใช้งาน สิ่งที่ต้องใส่ใจอย่างมาก คือ UI ต้องเรียบง่าย นั่นคือง่ายต่อการสร้างมันขึ้นมา และต้องมีการกำหนดมาตรฐานต่าง ๆ ขึ้นมา เพื่อสรุปข้อตกลงในการทำงานร่วมกัน ทำให้เราสามารถสร้าง library กลางเพื่อให้คนอื่น ๆ นำไปใช้ได้ นั่นแสดงว่าทั้ง UI designer และ Developer จำเป็นต้องพูดคุยกัน เพื่อทำให้ App โตไปอย่างยั่งยืน แถมทำให้ทั้ง App มันเข้ากัน ไม่ใช่ว่า แต่ละหน้า แต่ละ feature ไปกันคนละทาง !!

มาถึงเรื่องที่ชอบมาก ๆ ก็คือ เรื่องของ Code

เป้าหมายของทีมพัฒนา คือ พยายามที่จะลด จะตัด dependency ต่าง ๆ ออกไป ให้เหลือเฉพาะสิ่งที่จำเป็นหรือใช้งานเท่านั้น โดยในแต่ละ component จะมีหน้าที่การทำงานเฉพาะเจาะจงตาม use case ทำให้เกิดการเขียน code หรือ library ขึ้นมาใช้เอง เช่น JSON parser ไม่ใช้ Dependency Injection library เนื่องจากทำให้ขนาดของ App ใหญ่ขึ้น แถมซับซ้อนขึ้นอีก และกระทบต่อ performance แน่นอน ยังไม่พอนะ ใน App จะไม่มี Google Play Library อีกด้วย เนื่องจากเขียน code ขึ้นมา เพื่อจัดการกับ GCM เอง สิ่งที่นักพัฒนาต้องเรียนรู้คือ หลีกเลี่ยง MultiDex โดยมันคือปัญหาของ App ขนาดใหญ่ทุก App แน่นอนว่า ส่งผลต่อขนาดและ performance อย่างแรง หนัก ๆ เลยก็คือ เวลาในการ build แต่ละครั้งนานมาก !! ใช้ memory เยอะมาก !! ซึ่งนักพัฒนาทุกคนน่าจะกำลังประสบภัยกันปัญหานี้อยู่ ดังนั้นทีมพัฒนา App ของ Instagram จะใส่ใจเรื่องนี้มาก ๆ จะไม่ให้เกิด multidex ขึ้นมาใน App เลย ดังนั้นสิ่งที่ต้องทำก็คือ ดูแลการใช้งาน dependency library ต่าง ๆ อย่างใกล้ชิด ในแต่ละ library ที่เขียนหรือนำมาใช้ ต้องมีชุดการทดสอบครอบคลุม มิเช่นนั้น จะไม่ยอมรับในการเปลี่ยนแปลงนั้น ๆ รวมทั้งจัดการเรื่องจำนวนของ method count ซึ่งเราต้องทั้งสนใจและใส่ใจในสิ่งที่กำลังสร้างอยู่เสมอ ลองนำไฟล์ APK ของ Instagram App มาเปิดด้วย Analyze APK แสดงดังรูป instagram-01
สุดท้ายแล้ว ประโยคที่ผมชอบมาก ๆ ก็คือ The average engineer spends 20–40% of her day on various code review and mentorship activities.

สรุปเนื้อหาเรื่อง Effective Android Development จากงาน DroidCon Berlin

$
0
0

android-productive-00

android-productive-00 ช่วงนี้ดู Slide และฟัง session ต่าง ๆ จากงาน DroidCon Berlin มี session ที่น่าสนใจเกี่ยวกับ Android เยอะเลย หนึ่งในนั้นคือ Effective Android Development ทำการอธิบายว่า นักพัฒนา software นั้น ไม่ใช่มีเพียงความรู้ความชำนาญในเรื่องนั้น ๆ เท่านั้น แต่ยังต้องรู้จักเลือกเครื่องมือให้เหมาะกับงานอีกด้วย
Android ก็เช่นกัน เพื่อเพิ่ม productivity ในการพัฒนาระบบ รวมทั้งทำให้ App ที่พัฒนามีความเสถียรมากขึ้น ไม่ใช่เพียงนั่งทำงานไปวัน ๆ เท่านั้น
มาดูกันว่ามีคำแนะนำดี ๆ อะไรบ้าง ?

เริ่มจาก Android Studio

ทำการตรวจสอบไฟล์ manifest ก่อนที่จะทำการ build ไฟล์ APK ด้วย Merged Manifest Viewer ซึ่งเป็น feature ที่มีมากับ Android Studio 2.2 ใช้งานง่าย ๆ แค่เปิดไฟล์ AndroidManifest.xml ก็จะเห็น tab Merged Manifest แล้วนะ แสดงผลการทำงานดังรูป android-productive-01 หัดใช้ Find Sample Code กันบ้างนะ !! สำหรับการเรียนรู้ API ใหม่ ๆ แน่นอนว่ามีมากับ Android Studio 2.2 นั่นเอง แสดงดังรูป android-productive-02 รู้กันไหมว่า Android Studio มันมี Local History นะ ตามจริงมันเป้นความสามารถของ IntelliJ IDEA นั่นเอง ถ้าเราต้องการอยากรู้ว่า code ในเครื่องเรามีการเปลี่ยนแปลงอะไรไปบ้าง (หลังจากการ commit) สามารถเข้าใช้งานโดยการ click ขวาที่ไฟล์นั้น ๆ จากนั้นทำการเลือก Local History หรือไปที่เมนู VCS -> Local History ก็ได้เหมือนกัน แสดงผลดังรูป android-productive-03 เมื่อทำการเปลี่ยนแปลง code และ resource ต่าง ๆ แล้วอยากเห็นผลเร็ว ๆ เป็นความเจ็บปวดระดับโลกของชาว Android แน่นอนว่า วิธีการแก้ไขปัญหาคือ ใช้เงินซื้อเครื่องแรง ๆ สิ แต่ในปัจจุบันก็มีเครื่องมือช่วยมากขึ้น (แต่ก็ยังต้องใช้เครื่องแรง ๆ อยู่ดี) ไม่ว่าจะเป็น JRebel และ Instant Run ทำให้เราเห็นผลการเปลี่ยนแปลงได้อย่างรวดเร็ว โดยที่ JRebel นั้นจะมีความสามารถมากกว่า แต่ก็ต้องแลกมาด้วยค่า licence นะครับ ซึ่งใน session ทำการสรุปข้อแตกต่างระหว่างทั้งสองไว้ดังนี้ android-productive-04

มาดูเครื่องมืออื่น ๆ ที่ช่วยในระหว่างการพัฒนาบ้างดีกว่า

เป้าหมายเพื่อช่วยวัดประสิทธิภาพในการทำงานของระบบ สิ่งที่ต้องรู้ก็คือ
  • จะวัดความเร็วในการทำงานอย่างไร ?
  • จะทำการแก้ไขและปรับปรุงอย่างไร ?
เริ่มด้วยการ debug และวิเคราะห์การทำงานในของแต่ละ method ด้วย Hugo กันเลย รวมทั้ง pidcat สำหรับดู log แบบง่าย ๆ จะได้ไม่ต้องมานั่งอ่าน log ใน logcat กันต่อไป เนื่องจากมันอ่านยากมาก ๆ ถ้าต้องการดูและวิเคราะห์ log จากระบบ Network ล่ะ จะทำอย่างไร ? เนื่องจาก App ส่วนใหญ่ต้องทำการผ่านระบบ network เสมอ ดังนั้นนักพัฒนาจะทำอย่างไรดีล่ะ ?
  • เปิด log ทั้งหมดในระหว่างการพัฒนาไปเลย แน่นอนว่าทำให้ performance ของระบบลดลง
  • ถ้าใน app ใช้ library ที่ต้องทำงานผ่านระบบ network แล้วต้องทำการแก้ไข configuration เพื่อให้แสดง log การทำงานออกมา
  • ในระหว่างที่ทีม Tester/QA ทำการทดสอบไม่มี console เพื่อดูผลการทำงานนะ ดังนั้นเราไม่สามารถ monitoring traffice ต่าง ๆ ได้เลย
คำถามคือ ทำอย่างไรดีล่ะ ? ตอบได้เลยว่ามีเครื่องมือช่วยเหลือนะ เช่น Charles Proxy และ Facebook Stetho ปล. เมื่อไรในไทยจะมีงานแบบนี้บ้างนะ !!

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

$
0
0

graphql-00

graphql-00 วันนี้ได้พูดคุยเรื่อง GraphQL กันนิดหน่อย ซึ่งเป็นความรู้ใหม่ ๆ ที่ได้รับกลับมา จึงกลับมานั่งสรุปในเรื่องพื้นฐานที่สำคัญประกอบไปด้วย
  • GraphQL คืออะไรกันแน่ ?
  • ทำไมเราต้องให้ความสนใจด้วยล่ะ ?
  • มันจะทำให้ชีวิตนักพัฒนาดีขึ้นอย่างไร ?
มาเริ่มกันเลย ปล. เริ่มด้วยการไปค้นหาข้อมูล จะเจอ link ที่ต้องอ่านคือ GraphQL Introduction

GraphQL คืออะไรกันแน่ ?

คือ query language หรือการเข้าถึงข้อมูลจาก API ของระบบ query ต่าง ๆ จะถูกประมวลผลที่ฝั่ง server และจะทำการตรวจสอบโครงสร้างของ query กับโครงสร้างข้อมูลที่ได้กำหนดไว้ นั่นหมายความว่า ผู้ให้บริการ API จะต้องทำการกำหนดโครงสร้างของข้อมูลไว้ก่อนเสมอ ซึ่งเป็นหนึ่งปัญหาหลักของ REST API ดังนั้น GraphQL จึงเป็นอีกหนึ่งทางเลือกในการสร้าง API ที่ดีกว่า REST อีกทั้งไม่ได้ผูกติดกับ database และ ที่จัดเก็บข้อมูลใด ๆ ทั้งนั้น ที่สำคัญมันไม่ใช่ query language สำหรับการดึงข้อมูลจาก database เหมือน SQL นะ แต่มันเป็นภาษาสำหรับการดึงข้อมูลในระดับ application ซึ่งสามารถทำงานร่วมกับระบบ backend ใด ๆ ก็ได้ เช่น
  • SQL
  • RDBMS
  • NoSQL
  • File system
  • Existing system ใด ๆ ก็ได้
graphql-01 โดยรวมแล้ว มันคือ query language ที่มีโครงสร้างชัดเจน  (Schema) คุ้น ๆ กันไหมว่ามันคล้ายอะไร ?

เพื่อความเข้าใจมากยิ่งขึ้น มาสร้าง GraphQL server กันดีกว่า

ซึ่งใน community นั้นมีหลายภาษามาก ๆ ในบทความนี้จะลองสร้างภาษา JavaScript โดยตัวอย่าง source code อยู่ที่ Github::Hello GraphQL สิ่งที่ต้องการสร้างแบบง่าย คือ สร้าง API สำหรับดึงข้อมูลคะแนนสูงสุด ด้วย query ดังนี้ [code] query getHighestScore {score} [/code] ดังนั้นสิ่งที่เราต้องทำก่อนคือ กำหนด schema ของการ query กันก่อน ประกอบไปด้วย
  • ชื่อของ query คือ getHighestScore
  • โดย field ที่ต้องการคือ score
สามารถเขียน code ได้ดังนี้ [gist id="b1178a1f94974d3ce6d89e5e251a994d" file="myschema.js"] จากนั้นทำการ start server และทดสอบ query ข้อมูลผ่าน curl ดังนี้ [gist id="b1178a1f94974d3ce6d89e5e251a994d" file="query01.txt"] มีคำถามว่า ถ้าเราต้องการอยากรู้ว่า schema มีโครงสร้างอย่างไรบ้าง ? จะดูอย่างไร ? โดยที่ GraphQL มีคำตอบให้คือ Introspection ดังตัวอย่าง [gist id="b1178a1f94974d3ce6d89e5e251a994d" file="query-schema01.txt"]

ตัวอย่างนี้มันดูง่ายไป ดังนั้น ลองมาดูตัวอย่างยาก ๆ ขึ้นมานิดหน่อย

เป็นการดึงข้อมูลผู้ใช้งานทั้งหมดในระบบออกมา โดยผู้ใช้งานแต่ละคนมีข้อมูลดังต่อไปนี้
  • รหัส
  • ชื่อ
  • นามสกุล
  • อายุ
[code] query allUser { id, firstname, lastname, age } [/code] ผลลัพธ์ที่ต้องการเป็นดังนี้ [gist id="b1178a1f94974d3ce6d89e5e251a994d" file="result_alluser.json"]

ดังนั้นมาเริ่มสร้าง API กันดีกว่า

ขั้นตอนที่ 1 สร้าง UserType ขึ้นมาก่อน เพื่อกำหนดว่าผู้ใช้งานแต่ละคนมีโครงสร้างอย่างไร ดังนี้ [gist id="b1178a1f94974d3ce6d89e5e251a994d" file="usertype.js"] ขั้นตอนที่ 2 สร้าง query ชื่อว่า allUser ขึ้นมาในส่วนของ query ดังนี้ [gist id="b1178a1f94974d3ce6d89e5e251a994d" file="user_query.js"] ขั้นตอนที่ 3 ทำการ restart server และทดสอบผ่าน curl ได้ผลดังนี้ ตัวอย่างผู้ใช้งานสามารถเลือก field ที่ต้องการได้อีกด้วย โดยจะให้แสดงผลข้อมูลเฉพาะ id และ firstname เท่านั้น [gist id="b1178a1f94974d3ce6d89e5e251a994d" file="query_alluser.txt"]

ตัวอย่างที่ผ่านมาคือ API ที่อ่านข้อมูลเพียงอย่างเดียวเท่านั้น

แต่ถ้าเราต้องการแก้ไข เพิ่มเติม และ ลบข้อมูลล่ะ จะทำอย่างไร ? ซึ่งทาง GraphQL จะเรียกการทำงานเหล่านี้ว่า Mutations เช่นต้องการทำ API สำหรับเพิ่มข้อมูลผู้ใช้งานขึ้นมา จะต้องทำอย่างไร มาดูกัน [code] mutation addUser { id: 4, first name: “first name 04”, last name: “last name 04”, age: 40 } [/code] สังเกตุว่าในการสร้าง addUser นั้น จะต้องทำการกำหนด argument ด้วย เหมือนกับการประกาศ function/method นั่นเอง โดยหลังจากที่เพิ่มผู้ใช้งานใหม่ไปแล้ว จะส่งข้อมูลผู้ใช้งานทั้งหมดกลับมาก สามารถเขียน code ได้ดังนี้ [gist id="b1178a1f94974d3ce6d89e5e251a994d" file="mutation_adduser.js"] จากนั้นทำการ run ผ่าน curl ได้ผลลัพธ์ดังนี้ [gist id="b1178a1f94974d3ce6d89e5e251a994d" file="mutation_adduser.txt"]
เพียงเท่านี้ก็สามารถสร้าง GraphQL APIs แบบง่าย ๆ ได้แล้ว และน่าจะพอทำให้เห็นภาพของ GraphQL มากขึ้นนะครับ
และยังมีรายละเอียดอีกมากมายให้ศึกษายกตัวอย่างเช่น

เป้าหมายของ Code Review คืออะไร ?

$
0
0

review-code

review-code ในการพัฒนา software นั้นการทำงานเป็นทีมมันสำคัญมาก ๆ ยิ่งเรื่องของ code ที่มีคุณภาพ (Code Quality) ยิ่งสำคัญมากขึ้นไปอีก แต่สิ่งยากกว่าคือ จะทำการ review code อย่างไรดี ? เนื่องจากแต่ละคนในทีมล้วน มีสิ่งที่ต้องทำ มีสิ่งที่ต้องแก้ไข มีการเรียงลำดับความสำคัญของงานที่ต่างกัน ที่สำคัญคือ ทีมส่วนใหญ่เน้นการทำให้เสร็จมาก่อนทำให้ดี !! สิ่งที่ตามมาคือ การ rework หรือแก้งานเดิม ๆ อยู่ตลอดเวลา ดังนั้นก่อนอื่นเรามาทำความเข้าใจกับการ review code ก่อนว่า มันมีเป้าหมายอะไรบ้าง ? เพื่อทำให้ทุกคนในทีมมีความเข้าใจตรงกันและเห็นความสำคัญอีกด้วย

เหตุผลที่ 1 คือ เป็นการสอน developer คนอื่น ๆ ในทีม

เนื่องจากในการพัฒนา software นั้นมันมีความซับซ้อนสูงมาก ๆ แต่ละคนอาจจะรู้เพียง 5-10% เท่านั้น ทำให้เราไม่รู้เลยว่า สิ่งที่ได้แก้ไขหรือเพิ่มเข้าไปนั้นส่งผลอะไรต่อระบบบ้าง มันเป็นทั้งของจำกัดของคน และ ต้นเหตุของปัญหาหลาย ๆ อย่าง ดังนั้นถ้าต้องการแบ่งปันความรู้หรือสอนคนอื่น ๆ ในทีม ให้มีความรู้ในสิ่งที่เรารู้ วิธีการที่ดีมาก ๆ คือ การ review code และ pair programming จะทำให้เราเห็นความเชื่อมโยงต่าง ๆ ของระบบ นั่นทำให้เราเห็นผลกระทบโดยรวมมากยิ่งขึ้น

เหตุผลที่ 2 คือ ปรับปรุงเรื่องคุณภาพของ code

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

เหตุผลที่ 3 คือ การสร้างวัฒนธรรมในการพัฒนาของทีม

โดยปกติทุกทีม จะมี guideline สำหรับการเขียน code จะมี style สำหรับการเขียน code ซึ่งแต่ละทีมก็ควรจะปฏิบัติตามเช่นกัน แต่เราจะมั่นใจได้อย่างไรว่า ทุกคนทำตามสิ่งที่ตกลงกันไว้ หรือ เข้าใจถูกต้องหรือไม่ ? ดังนั้นสิ่งที่ทีมควรทำคือ การ review code และที่สำคัญแต่ละทีมก็ควรมีการ review code ที่แตกต่างกันไป ตามลักษณะของทีม ตามลักษณะของคน ตามลักษณะของงาน ไม่ควรใช้รูปแบบเดียวกันในทุก ๆ ระบบ

เหตุผลที่ 4 คือ ทำให้เรามีความเชื่อมั่นมากขึ้น

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

คำถามที่น่าสนใจ คือ ทีมของคุณทำการ review code บ้างหรือยัง ?

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

สรุปข้อดีและข้อเสียของ Test Driven Development (TDD)

$
0
0

tdd-01

tdd-01 วันนี้มาแนะนำการพัฒนาระบบงานด้วยแนวคิด TDD (Test-Driven Development) จึงทำการสรุปข้อดีและข้อเสียของแนวคิดนี้ไว้นิดหน่อย เพื่อทำให้เข้าใจกันมากขึ้น

เริ่มต้นด้วยข้อดี

ทำให้เราเขียน code เท่าที่จำเป็นเท่านั้น ถ้าเราปฏิบัติตามกฏและแนวคิดของ TDD คือ เราจะไม่เขียน production code ใด ๆ ถ้า test ทั้งหมดทำงานไม่ผ่าน ถ้าต้องการเพิ่ม feature ให่เข้าไป ต้องเริ่มจากการเขียน test ก่อนเสมอ โดยที่ production code ต้องเป็น code ที่เรียบง่าย หรือเพียงพอที่ทำให้ test ผ่าน ซึ่งจะทำให้เราได้ production code ที่จำเป็นจริง ๆ เท่านั้น ทำให้ code แยกกันอย่างชัดเจน เนื่องจากเราเริ่มต้นจากการเขียน test ดังนั้นถ้าต้องการทดสอบได้ง่าย ๆ แล้ว code แต่ละส่วนต้องไม่ผูกมัดกันแน่นจนเกินไป code ส่วนไหนควรอยู่ด้วยกันก็ไม่จำเป็นต้องแยกออกจากกัน ทำให้ code อยู่เป็นสัดเป็นส่วน เป็นกลุ่มเป็นก้อน ซึ่งเรามักจะเรียกว่า modular นั่นเอง ทำให้ง่ายต่อการดูแลรักษา เมื่อ code แยกกันอยู่ในที่ที่มันควรจะอยู่ ทำให้เมื่อทำการเพิ่ม featureและแก้ไขแล้ว จะลดผลกระทบลงไปอย่างมาก ตลอดจนมีชุดของการทดสอบที่ครอบคลุม ทำให้เรามั่นใจได้ว่า สิ่งที่แก้ไขมันทำงานถูกต้องหรือไม่ ทำให้เรามั่นใจได้ว่า สิ่งที่แก้ไขมันกระทบการทำงานส่วนอื่น ๆ หรือไม่ ข้อดีอีกอย่างคือ ทำให้เรามีความมั่นใจเมื่อต้อง refactor code หรือการปรับปรุงโครงสร้างของ code ให้ดีขึ้น สิ่งที่ตามมาก็คือ Test Coverage ที่สูงขึ้น Test coverage คือค่าที่บอกว่า test ที่เขียนมานั้น ครอบคลุม production code มากน้อยเพียงใด ซึ่งมันทำให้เรามั่นใจได้มากขึ้น ว่า test ที่เราเขียนมันไปครอบคลุม code ส่วนไหนบ้าง หรือไม่ครอบคลุมส่วนไหนบ้าง และถ้าเขียน test ดี ๆ แล้ว มันจะเป็นเอกสารชั้นดีเลย เนื่องจากใน test นั้น จะทำการอธิบายว่า production code ทำงานอย่างไร ? production code ใช้งานอย่างไร ? production code มีพฤติกรรมการทำงานอย่างไรบ้าง ? สุดท้ายจะช่วยทำให้ลดการ debugging ลงไปเยอะมาก ๆ ลองถามตัวเราเองสิว่า ใช้เวลาไปกับการ debug เยอะไหม ? ใช้เวลากับการ copy ข้อความจากการ debug เพื่อไปค้นหาผ่าน internet เยอะไหม ? ทำการ debug บ่อยไหม ? ถ้าตอบว่าใช่ ลองมาเขียน test เพื่อทดสอบกันไหม เพื่อทำให้เราเห็นข้อผิดพลาดเหล่านั้น จากนั้นจึงลงมือแก้ไขต่อไป

ปิดด้วยข้อเสีย

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

แนะนำวิธีการเขียน code ให้ดีขึ้น

$
0
0

code_geass_going_crazy_by_hitomijaejoong-d6cwlr3

code_geass_going_crazy_by_hitomijaejoong-d6cwlr3 ค่ำนี้อ่าน slide เรื่อง Idiomatic Go Tricks จากงาน Go UK Conference ซึ่งมีคำแนะนำดี ๆ เกี่ยวกับการเขียน code มากกว่าการเขียน code ให้เสร็จ ๆ ไป เพื่อทำให้ code ดูแลรักษาได้ง่าย ประกอบไปด้วยสิ่งต่าง ๆ ดังต่อไปนี้ 1. ให้เขียน code ที่เป็น happy path หรือ flow การทำงานหลักชิดซ้ายเข้าไว้ เพื่อทำให้ code อ่านง่าย เข้าใจได้รวดเร็ว ดังตัวอย่าง [code] step_01() step_02() step_03() step_04() [/code] 2. อย่าซ่อน happy path ไว้ลึก ๆ หรือ ซับซ้อน !! ซึ่งทำให้อ่านยาก แถมแก้ไขยากอีกต่างหาก ถ้านึกไม่ออกก็ให้คิดถึง code คันธนู หรือ หัวลูกศรนั่นเอง ดังตัวอย่าง [code] step_01() step_02() step_03() step_04() return //happy path return // fail path return //fail path return //fail path [/code] 3. พยายามให้จบการทำงานอย่างรวดเร็วทั้ง happy path และ fail path เช่นการตรวจสอบข้อมูล ถ้าตรวจสอบแล้วไม่ผ่านก็ให้จบการทำงานไปเลย รวมทั้งหลีกเลี่ยงการ return ที่ else block ดังตัวอย่าง [code] if isValid() { return or throw exception } //Next process [/code] 4. ในส่วนของ happy path นั้นควรทำการ return ไว้บรรทัดสุดท้ายของการทำงาน 5. พยายามเขียน code ในแต่ละ function/method ให้เล็กและอ่านง่าย (Clean and Small) ถ้าพบว่า code ในแต่ละ function/method มีจำนวนมาก ให้ทำการแยกไปเป็น function/method ใหม่ซะ
ซึ่งถ้า developer ทำตามนี้แล้ว มั่นใจได้เลยว่า code จะดีและอ่านง่ายขึ้น

ว่าด้วยการปรับปรุงคุณภาพของ code ให้ดีขึ้น

$
0
0

code-quality

code-quality มีคำถามที่น่าสนใจมาก ๆ คือ เราต้องทำอย่างไรบ้างเพื่อดูแลรักษาคุณภาพของ code ? เราต้องทำอย่างไรบ้างเพื่อปรับปรุงคุณภาพของ code ให้ดีขึ้น ? ลองมาหาตอบคำถามกันหน่อยสิ

1. เริ่มต้นด้วยการเขียน Unit test ที่มีประโยชน์

โดยที่การเขียน unit test นั้นย่อมมี learning curve อยู่แล้ว แต่มันไม่ใช่ปัญหาใหญ่อะไรมากไปกว่าการไม่เขียน เป็นสิ่งที่ developer ต้องสนใจ ใส่ใจและฝึกฝน เพื่อให้เกิดเป็นทักษะของตนเอง จนทำให้กลายเป็นนิสัยของเราไปเอง
ผลที่จะได้รับกลับมาก็คือ คุณภาพของ code ที่ดีขึ้นกว่าเดิม เนื่องจาก unit test จะบังคับให้เราเขียน code ที่ง่ายต่อการทดสอบ นั่นก็คือ code แต่ละส่วนจะไม่ผูกมัดกันแน่นหรือเรียกว่า Tight coulping นั่นเอง ซึ่งทำให้การออกแบบมันดีขึ้นตามไปด้วย
การเขียน unit test นั้นต้องพิจารณาถึงความคุ้มค่าด้วยนะ แต่สำหรับผู้เริ่มต้นให้เขียนเยอะ ๆ เข้าไว้นะครับ จะทำให้เรารู้ว่าควรหรือไม่ควรเขียนอะไร อย่ามานั่งเถียงกันว่าจะเขียนหรือไม่เขียนดี ซึ่งมันเสียเวลาโดยเปล่าประโยชน์

2. แยกส่วนการทำงานออกจากกันอย่างเหมาะสม

สิ่งที่ developer ต้องให้ความสนใจก็คือ การจัดการเรื่อง dependency graph ที่เกิดขึ้นภายใน code ที่พัฒนา ว่าเราจัดการได้ดีเพียงใด ส่วนใหญ่มักจะแยกออกเป็นส่วนเล็ก ๆ แยกตามหน้าที่การทำงาน เช่น module และ namespace เป็นต้น ลด ละ เลิก เรื่องการใช้ Global variable ที่ถูกใช้งานจากทุก ๆ ส่วน จนสุดท้ายทำให้เราไม่รู้เลยว่า ใครมาแก้ไขหรือเปลี่ยนแปลงค่าอะไรบ้าง เป็นสาเหตุให้เกิดข้อผิดพลาดมากมายตามมา มีคำถามที่ต้องตอบให้ได้ในการออกแบบและเขียน code คือ ในส่วนการทำงาน A ต้องการ B จริง ๆ หรือไม่ ?

3. หัดเขียน code เพื่อคนอื่น ๆ บ้าง

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

4. ลดความซับซ้อนของ code ลงซะบ้าง

ค่าความซับซ้อนของ code วัดด้วยค่า Cyclomatic complexity เพื่อวัดดูว่าใน code มีเส้นทางที่เป็นไปได้กี่เส้นทาง ดังนั้น code ที่ดีมาก ๆ คือ ค่าความซับซ้อนเท่ากับ 1 !! แต่ในความเป็นจริงเรากลับพบเงื่อนไข และ เส้นทางมากมายใน code เช่น if-else ก็เกิด 2 เส้นทางแล้ว ลองคิดดูสิว่า เรามี if-elseif-else กันเยอะไหม ? ลองคิดดูสิว่า เรามี loop ซ้อน loop กันเยอะไหม ? ซึ่งก่อให้เกิดปัญหามากมาย ส่งผลต่อเวลาในการพัฒนา ส่งผลต่อเวลาในการทดสอบ ส่งผลต่อจำนวน bug ที่เยอะขึ้น ส่งผลต่อเวลาในการ debug !! ส่งผลต่อเวลาในการเพิ่ม แก้ไข code รวมทั้งส่งผลต่อคุณภาพของ code ด้วย ดังนั้นควรลดค่าความซับซ้อนของ code ให้ต่ำมาก ๆ นะครับ

5. ตั้งชื่อให้ชัดเจน สื่อสารถึงหน้าที่การทำงาน

เป็นสิ่งที่ developer บอกว่ายากมาก ๆ แต่มันกลับส่งผลต่อคุณภาพของ code อย่างมากเช่นกัน ดังนั้นต้องฝึก อ่าน และ เขียนเยอะ ๆ ชื่อแย่ ๆ นำไปสู่ความเข้าใจผิดมากมาย ดังนั้นถ้ามีโอกาสก็ช่วยปรับปรุงชื่อต่าง ๆ ให้ดี สื่อสารให้ตรงความต้องการมากขึ้นนะครับ ตัวอย่างเช่นยังมีคนเข้าใจว่า Java กับ Javascript มันเหมือนกันอยู่เลย !!

โดยสิ่งต่าง ๆ เหล่านี้เป็นสิ่งที่ยากน่าดู

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

สรุปการใช้งาน Scan และ Snapshot ของ Fastlane

$
0
0

fastlane-00

fastlane-00 หลังจากที่ได้แบ่งปันการใช้งาน Fastlane เพื่อสร้างระบบ Automation สำหรับ iOS app ตั้งแต่การ compile source code, Unit testing, UI testing ไปจนถึงการ deploy ไปยัง App Store จึงทำการสรุปการใช้งานพร้อมตัวอย่างไว้นิดหน่อย ซึ่งในบทความนี้ประกอบไปด้วย
  • Scan เป็นเครื่องมือสำหรับการ compile และ ทดสอบทั้ง Unit test และ UI Test
  • Snapshot เป็นเครื่องมือสำหรับการ snapshot หน้าจอ app ใน UI Test
มาเริ่มใช้งานกันดีกว่า

1. การใช้งาน Scan

เริ่มต้นด้วยการติดตั้ง [code] $gem install scan [/code] โดยที่ Scan เข้ามาเพื่อช่วยลดความยุ่งยากของการการใช้งานผ่าน xcodebuild นั่นเอง การใช้งานก็ง่ายมาก ๆ คือ [code] $scan [/code] เพียงเท่านี้ก็จะทำการ compile และทดสอบระบบงานให้ ทั้ง Unit test และ UI test และสามารถทำการ configuration ต่าง ๆ เพิ่มได้อีกเยอะ ซึ่งแนะนำให้สร้างไฟล์ Scanfile ขึ้นมา ด้วยคำสั่ง [code] $scan init [/code] ผลการทำงานเป็นดังรูป fastlane-01 โดยผลการทำงานจะอยู่ใน folder test_output ซึ่งประกอบไปด้วย 2 ไฟล์ คือ
  1. report.html
  2. report.junit
ปล. จะมีปัญหาในการสร้าง junit report ด้วย xcpretty เมื่อชุดการทดสอบไม่ผ่าน !!

2. การใช้งาน Snapshot

สิ่งที่ทีมต้องการ สิ่งที่หลาย ๆ คนต้องการ คือ ต้องการเห็นหน้าจอการทำงานของ app ทุกขั้นตอน ว่าทำงานถูกต้องหรือไม่ ? ว่าแสดงผลถูกต้องหรือไม่ ? แน่นอนว่า สิ่งที่ดีที่สุดคือ ก็ต้องทดสอบแบบ manual นี่แหละ แต่ถ้า app มีการทำงานเยอะมาก ๆ การทดสอบแบบ manual แบบทั้งหมดต้องใช้เวลามากมาย ดังนั้นถ้ามีเครื่องมือใช้ snapshot หน้าจอการทำงานแต่ละขั้นตอนให้ล่ะ ? มันน่าจะดีไม่น้อย ซึ่ง Snapshot ก็คือ หนึ่งในเครื่องมือที่ช่วยเหลือเรื่องเหล่านี้ ที่ทำงานร่วมกับ UI test นั่นเอง ดังนั้นจำเป็นต้องเขียน UI test ขึ้นมาด้วยนะ ถึงจะใช้งาน Snapshot ได้ เริ่มต้นด้วยการติดตั้ง [code] $gem install snapshot [/code] จากนั้นทำการ initial ก่อนเริ่มใช้งานด้วยคำสั่ง [code] $snapshot init [/code] จะทำการสร้างไฟล์ Snapfile ขึ้นมา รวมทั้งไฟล์ (ตัวอย่างเป็น Swift project)
  • SnapshotHelper.swift
  • SnapshotHelper2-3.swift
ซึ่งให้นำไปใส่ไว้ในส่วน UI Test นะครับ โดยในไฟล์นั้นประกอบไปด้วย configuration ที่น่าสนใจคือ
  • Devices ที่ต้องการให้ snapshot โดยปกติก็จะทดสอบ device และ simulator ทั้งหมดที่มี
  • Languages คือภาษาที่เราต้องการให้ทดสอบ เหมาะมาก ๆ สำหรับ app ที่รองรับมากกว่า 1 ภาษา
จำนวนครั้งในการทำงานและรูปที่ได้จะเท่ากับ จำนวน Device คูณกับจำนวน Language นั่นเอง ตัวอย่างเป็นการกำหนดให้ทดสอบบน 1 device และ 2 ภาษา [code] devices([ "iPhone 6s"]) languages([ "en-US", "de-DE" ]) [/code] ทำการแก้ไข code ใน UI Test นิดหน่อย เพื่อใช้งาน Snapshot ดังนี้ [gist id="27a2501dd2c0eab1103ac7347b22b0a5" file="UITest.swift"] จากนั้นทำการ run ด้วยคำสั่ง [code] $snapshot [/code] ผลการทำงานจะสร้างไฟล์รูปภาพและ ไฟล์ HTML fastlane-02 หน้าตาของไฟล์ HTML เป็นดังนี้ fastlane-03 ปล. ถ้ามีปัญหาว่าหา folder screenshots ไม่เจอ ก็ให้ทำการสร้างให้มันไปเองนะครับ Source code ตัวอย่างอยู่ที่ Github::Up1::Demo CI iOS

มาถึงตรงนี้เราก็พร้อมจะเริ่มต้นสร้างระบบ Automation สำหรับการพัฒนา iOS app แล้วนะครับ

ได้ทั้งการ compile code ได้ทั้งการทดสอบระดับ Unit และ UI ได้ทั้งการ snapshot หน้าจอการทำงานของ app ในขั้นตอนต่าง ๆ ต่อไปก็ไปจัดการเรื่อง certificated, การสร้างไฟล์ IPA และการ deploy ...
แต่ว่าวันนี้คุณเขียน Test สำหรับ iOS app กันแล้วหรือยัง ?

วิธีการแก้ไขปัญหาตามแนวคิด Test-Driven Development (TDD)

$
0
0

empnuwexfdhu2ubpk20x

empnuwexfdhu2ubpk20x จากหนังสือ TDD by Example ทำการอธิบายวิธีการแก้ไขปัญหา เพื่อย้ายจากสถานะ RED ไปยัง GREEN ตาม life cycle ของ TDD ไว้ 3 วิธีการคือ
  • Obvious implementation
  • Fake it until you make it
  • Triangulation
ซึ่งการจะเลือกใช้วิธีการใดนั้น มันขึ้นอยู่กับความรู้ความเข้าใจต่อปัญหาของ developer มันขึ้นอยู่กับแนวทางในการแก้ไขปัญหาของ developer มันขึ้นอยู่กับความสามารถของ developer จึงทำการสรุปพร้อมตัวอย่างไว้นิดหน่อย เพื่อทำให้เราสามารถเดินไปข้างหน้าได้อย่างสม่ำเสมอ จนสามารถแก้ไขปัญหาต่าง ๆ ได้ มาเริ่มกันเลย

1. Obvious implementation

มันคือเขียน code สำหรับแก้ไขปัญหานั้นได้ทันที ดังนั้นผู้แก้ไขปัญหาจำเป็นต้องมีความรู้เกี่ยวกับปัญหาอย่างชัดเจน รู้ว่าจะแก้ไขปัญหาอย่างไร รู้ว่าต้องเขียน code อย่างไรเป็นอย่างดี ทำให้สามารถเขียน code เพื่อแก้ไขปัญหาได้ทันที เช่นการคำนวณหาพื้นที่สี่เหลี่ยม สามารถเขียน code ได้ดังนี้ เริ่มต้นจากการเขียน test ก่อนเสมอ [gist id="d91095c709f0db4d211dc3dcfb85947d" file="test_01.java"] ซึ่งถ้าเราใช้วิธีการแก้ไขปัญหาแบบแรก สามารถเขียน code ได้ดังนี้ [gist id="d91095c709f0db4d211dc3dcfb85947d" file="solution_01.java"] แต่ลองคิดดูสิว่า ถ้าปัญหาที่เราต้องการแก้ไขมันยากและซับซ้อนล่ะ ? การจะเขียน code ออกมาทีเดียวทั้งหมดไม่น่าจะเป็นเรื่องที่ดีแน่ ๆ เนื่องจากต้องใช้เวลาแก้ไขนานมาก ๆ ดังนั้นมาดูวิธีการต่อไป

2. Fake it until you make it

ถ้าคุณรู้ปัญหา และ วิธีการแก้ไขปัญหา แต่ยังไม่มั่นใจในการเขียน code แนะนำให้ทำการ Fake ผลการทำงานก่อน เพื่อทำการการทดสอบผ่าน จากนั้นจึงหยุด และกลับมาดู code เพื่อวิเคราะห์ว่า ทำไมเราถึง fake คำตอบไว้ ? การ fake มีที่มาจากอะไรบ้าง ? มาดูตัวอย่างของการหาพื้นที่สี่เหลี่ยมเหมือนเดิม สามารถเขียน code ชุดแรกได้ดังนี้ [gist id="d91095c709f0db4d211dc3dcfb85947d" file="solution_021.java"] ผลก็คือทดสอบผ่านแน่นอน จากนั้นลองมาคิดหน่อยสิว่า สูตรการหาพื้นที่สี่เหลี่ยมคืออะไร ? มันคือกว้างคูณยาวใช่หรือไม่ ? ดังนั้นสามารถแก้ไข code ได้ดังนี้ [gist id="d91095c709f0db4d211dc3dcfb85947d" file="solution_022.java"] ผลก็คือทดสอบผ่านแน่นอน จากนั้นให้เริ่มแทนที่ค่าที่ Fake ขึ้นมาด้วยตัวแปรซะ จะทำให้ได้ code ที่สามารถแก้ไขปัญหาได้ แต่ถ้า developer ไม่รู้ว่าจะแก้ไขปัญหาอย่างไรล่ะ ? จะทำอย่างไรดี ?

3. Triangulation

เป็นวิธีการที่ผมใช้บ่อยมาก ๆ สำหรับการแก้ไขปัญหาที่เรายังไม่รู้วิธีการจริง ๆ แต่ใช้ test case เป็นตัวช่วยนำทาง รวมเข้ากับข้อมูลในการทดสอบ จากตัวอย่างการหาพื้นที่สี่เหลี่ยม เราสามารถเริ่มด้วยข้อมูลต่าง ๆ เหล่านี้ได้
  • Case 1 : width = 0, height = 0 ผลที่ได้คือ 0
  • Case 2 : width = 1, height = 1 ผลที่ได้คือ 1
  • Case 3 : width = 1, height = 2 ผลที่ได้คือ 2
ถ้าเขียน code จะได้ดังนี้ เริ่มที่ case 1 เพื่อทำให้ผ่านก็ทำการ fake ผลการทำงานได้เลย [gist id="d91095c709f0db4d211dc3dcfb85947d" file="case01.java"] มาที่ case 2 เป็นการเปลี่ยนค่า input เพื่อใช้แก้ไขปัญหาเดิม เพียงแค่ต่างมุมมองเท่านั้นเอง ถ้าต้องการให้ผ่านทั้ง 2 case จึงเกิดการสร้างตัวแปร width ขึ้นมาเก็บค่า [gist id="d91095c709f0db4d211dc3dcfb85947d" file="case02.java"] มาที่ case 3 เป็นการบังคับให้เราต้องสร้างตัวแปร height ขึ้นมา ซึ่งทำให้เกิดวอธีการแก้ไขปัญหาจริง ๆ ขึ้นมา [gist id="d91095c709f0db4d211dc3dcfb85947d" file="case03.java"] เป็นวิธีการที่ดูเหมือนโง่ แต่ก็โง่จริง ๆ แต่สิ่งที่เราได้รับกลับมาคือ ได้รู้ลำดับขั้นตอนการแก้ไข รวมทั้งเหตุผลของการสร้างตัวแปรชนิดต่าง ๆ ขึ้นมา ซึ่งเหมาะมากสำหรับการแก้ไขปัญหาที่ซับซ้อน สังเกตุไหมว่า การแก้ไขปัญหาแบบที่ 3 เหมือนดังรูป triangulation

สุดท้ายแล้ว ในการแก้ไขปัญหาต่าง ๆ

ขอให้เริ่มแบบ step-by-step โดยเริ่มจาก test case ที่ง่ายสุด ๆ ก่อน จากนั้นก็ค่อย ๆ เพิ่มความซับซ้อนเข้ามา เพื่อทำให้เรามีกำลังใจในการแก้ไขปัญหา
แต่ปัญหาหลักของ developer คือ ไม่สามารถแยกปัญหาใหญ่ ๆ ออกเป็นปัญหาย่อย ๆ ได้นะสิ !!

หัดลบ code ที่ไม่ใช้งานออกไปบ้างนะ !!

$
0
0

reduce-waste

reduce-waste อ่านบทความเรื่อง Honest Code ซึ่งเขียนมาตั้งแต่ปี 2005 มีใจความสำคัญว่า Code ส่วนไหนที่ไม่ถูกเรียกใช้งานจากส่วนอื่นก็ควรลบทิ้งไปซะ Code ส่วนไหนที่ไม่ถูกใช้งานจากผู้ใช้งานก็ควรลบทิ้งไปซะ ให้เหลือ code ที่จำเป็นเท่านั้นจริง ๆ จะได้ไม่ต้องมาเสียเวลากับ code ที่ไม่ใช้งาน ดังนั้นจึงนำมาแปลและสรุป ตลอดจนหาข้อมูลเพิ่มเติมบ้าง

เริ่มจากเรื่องราวที่ developer หลาย ๆ คนน่าจะเคยพบมา

เมื่อมี bug หรือพวก feature ใหม่ ๆ เข้ามา สิ่งแรกที่ต้องทำคือ หา code และ พยายามทำความเข้าใจกับ code ว่าทำงานอย่างไร ? จากนั้นก็พยายามหาวิธีแก้ไข แต่ทันใดนั้นเองคุณกลับไม่แน่ใจว่า code ในส่วนนั้น ถ้าแก้ไขแล้ว จะกระทบต่อส่วนใดบ้าง ? code ในส่วนนั้นถูกใช้งานจากที่ไหนบ้าง ? ดังนั้นสิ่งที่ต้องทำให้มั่นใจคือ หาให้ได้ว่า code ส่วนที่จะแก้ไขมันถูกใช้จากที่ไหนบ้าง ? และสิ่งที่ไม่น่าเชื่อก็เกิดขึ้น คือ เราเสียเวลาไปเป็นวัน ๆ เพื่อรู้ว่า code ส่วนนี้ไม่ถูกใช้งานจากส่วนไหนเลย !! code ส่วนนี้ไม่มีผู้ใช้งานเลย !! โดยในบทความอธิบายว่าในการพัฒนา software มีอยู่ 2 กลุ่มคือ
  1. กลุ่มที่เขียนแต่พวก framework และ library ซึ่งไม่เคยรู้เลยว่าหรือไม่สนใจเลยว่า จะมีใครมาใช้งาน code หรือไม่ !!
  2. กลุ่มที่เขียน Application code แน่นอนว่า code ที่เขียนคือ code ที่ถูกใช้งานอย่างแน่นอน
คำถามคือ เราอยู่ในกลุ่มไหน ? ดังนั้นจงหัดลบ code เหล่านี้ทิ้งไปบ้างนะ
แต่ ... ไม่กล้าลบนะสิ เพราะว่า กลัว !! เดี๋ยวงานจะเข้า

ถ้าต้องการลบ code เราต้องการวิธีที่ทำให้มั่นใจสินะ !!

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

ดังนั้นสิ่งที่เราต้องการคือ code บน production ถูกใช้งานหรือไม่ ?

หรือเราเรียกว่า coverage in production จะไปเขียน test case คงไม่ใช่ที่ แต่สิ่งที่ต้องทำก็คือ ต้องเพิ่ม logging หรือ analytic tool เพื่อทำให้เรารู้ว่า code ส่วนไหนไม่ถูกใช้งานจากผู้ใช้งานจริง ๆ แน่นอนว่าต้องเกิด overhead ขึ้นมาพอสมควร แต่การลงทุนย่อมต้องมีความเสี่ยงเสมอ แต่ถ้าต้องการลด overhead ต่าง ๆ ลงไป ก็ให้เก็บข้อมูลเฉพาะส่วนที่ต้องการ หรือส่วนที่น่าสงสัยก็น่าจะเพียงพอ จากนั้นทำการสรุปและวิเคราะห์จากผลการทำงาน เพื่อทำการลบ code ที่ไม่จำเป็นทิ้งไปเสียบ้าง แล้วมันจะทำให้คุณเสียเวลาน้อยลงไป
วันนี้ developer หัดลบ code ที่ไม่ใช้งานออกไปบ้างหรือยัง ?
Reference Websites https://michaelfeathers.silvrback.com/to-kill-code http://www.miqu.me/blog/2016/08/16/knowing-when-to-delete-code/

Write clear code, NOT clever code

$
0
0

clever-code

clever-code จากหนังสือ Practice of an Agile Developer มีคำแนะนำเกี่ยวกับวิธีการปรับปรุงความสามารถของ developer มากมาย ทั้ง soft skill และ technical skill แต่มีประโยคหนึ่งในหนังสือเล่มนี้ที่น่าจะโดนมาก ๆ คือ
Write clear code, NOT clever code
เป็นความสามารถที่สำคัญมาก ๆ ของ developer ควรจะมีไว้

ผมคิดว่า developer ส่วนใหญ่

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

แต่สิ่งที่แปลกก็เกิดขึ้นมาจากทีม !!

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

เมื่อไปถามคนในทีมเกี่ยวกับ code เหล่านี้พบว่า

code ที่เขียนขึ้นมานั้น perfect มาก ๆ code ที่เขียนขึ้นมานั้นมี pattern ที่ดีมาก code ที่เขียนขึ้นมานั้นทำงานได้อย่างถูกต้อง แต่ code ที่เขียนขึ้นมานั้น ไม่มีใครอ่านรู้เรื่องเลย !! code มันไม่ชัดเจน code มันซ่อน logic ต่าง ๆ ไว้เยอะมาก code มันซ่อน magic ต่าง ๆ ไว้เยอะมาก จนทำให้คนอื่น ที่ไม่ใช่เจ้าของ code ไม่รู้เรื่องเลย บางครั้งความสามารถของคนมันไม่เท่ากัน บางครั้งจินตนาการของคนมันไม่เท่ากัน บางครั้งความเข้าใจปัญหาไม่เท่ากัน

ดังนั้นสิ่งที่ควรคิดเมื่อต้องเขียน code คือ

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

สุดท้ายแล้ว เราไม่ได้ต้องการ code ที่สมบูรณ์แบบ

แต่เราต้องการ code ที่ชัดเจน นั่นหมายถึงคนในทีมสามารถเข้ามาดูต่อได้ง่ายนะครับ
If you love writing code-- really, truly love to write code-- you'll love it enough to write as little of it as possible. จาก codinghorror.com
Reference Websites http://blog.teamtreehouse.com/tips-for-writing-better-code https://medium.com/@mikesherov/writing-clear-code-not-clever-code-d6b90353a3c5#.c0vqy7l6b http://www.codethinked.com/dont-be-clever https://www.quora.com/How-do-I-learn-to-write-simpler-more-efficient-code-with-fewer-lines https://www.quora.com/What-are-some-of-your-personal-guidelines-for-writing-good-clear-code https://blog.codinghorror.com/the-best-code-is-no-code-at-all/

แนะนำ Docker image สำหรับติดตั้ง Elasticsearch และ Kibana

$
0
0

elasticsearch

docker-es ทีมพัฒนาของ Elastic ได้ปล่อย beta version ของ Docker Image สำหรับ Elasticsearch และ Kibana ออกมาให้ใช้งาน (Official Image) ซึ่งไม่แยก image หรือการติดตั้งออกจากกันอีกแล้ว รวมกันไปเลย ซึ่งทำให้ชีวิตนักพัฒนาง่ายขึ้นมาอีกหน่อย ดังนั้นมาลองใช้งานกันดีกว่า ปล. Docker image นั้นทาง Elastic ได้สร้าง private registry ขึ้นมาเอง อยู่ที่ docker.elastic.co/elasticsearch

เริ่มจากสิ่งที่ต้องรู้ไว้นิดหน่อยคือ

Image นี้จะทำการติดตั้ง elasticsearch อีกทั้งยังทำการติดตั้ง X-Pack ซึ่งจะติดตั้งสิ่งที่ต่าง ๆ เหล่านี้มาให้เอง
  • Security
  • Monitoring
  • Alerting
  • Reporting
  • Graph
ส่วน kibana ก็แยกออกไป ซึ่งไม่สะดวกเลย ดังนั้นทาง Elastic จึงสร้างไฟล์ configuration สำหรับ Docker Compose ออกมาให้ ซึ่งไม่ใช่อะไรใหม่เลย เนื่องจากนำ Elasticsearch docker มารวมกับ Kibana docker เท่านั้นเอง

การใช้งานก็ง่ายมาก ๆ ด้วยคำสั่ง

Docker compose file อยู่ที่นี่
[code] $export ELASTIC_REG=docker.elastic.co/elasticsearch $docker-compose up [/code] โดยการใช้งานก็ยังผ่าน port เดิมคือ Elasticsearch ผ่าน port 9200 Kibana ผ่าน port 5601 ดังรูป เข้าใช้งาน Elasticsearch 5.x elasticsearch เข้าใช้งาน Kibana 5.x kibana-5-0-login ปล. username และ password สำหรับเข้าใช้งาน คือ
  • username=elastic
  • password=changeme
สามารถเข้าไปเปลี่ยนได้ใน index ชื่อว่า users ผ่าน Kibana หรือ ผ่าน CURL ก็ได้ เพียงเท่านี้เราก็สามารถติดตั้งและใช้งาน Elasticsearch + Kibana ได้อย่างสบายใจแล้วนะ ทำให้สามารถทดสอบและทดลองอะไรใหม่ ๆ ได้รวดเร็วขึ้นไปอีก ปล. Docker image นี้เป็น beta version นะ ไม่แนะนำให้ไปใช้บน production server นะครับ Reference Website https://www.elastic.co/blog/releasing-beta-version-of-elastic-docker-images

วิธีลดจำนวนการทดสอบแบบ Manual ของ Mobile app

$
0
0

do-you-need-a-mobile-app

do-you-need-a-mobile-app ผลการสำรวจเรื่อง Why App Succeed ? จาก Perfecto พบว่าในรูปแบบการทดสอบ Mobile App นั้นเป็นดังนี้
  • 30% เป็นการทดสอบแบบอัตโนมัติ
  • 70% เป็นการทดสอบแบบอัตโนมือ !!
การทดสอบ Mobile App ยังคงเป็น manual test เป็นหลัก แต่สิ่งที่ขาดไปไม่ได้เลยคือ การทดสอบแบบอัตโนมัติ ดังนั้นมาดูวิธีการเลือกรูปแบบการทดสอบกันหน่อย เพื่อทำให้การทดสอบสนุกและเจ็บปวดน้อยลง

1. ทำการวิเคราะห์จากชุดการทดสอบที่มี

ว่าควรจะทำการทดสอบแบบใดดี Manual testing vs. Automation testing สิ่งที่ได้กลับมาคือ
  • เพื่อทำให้เห็นว่าชุดการทดสอบต่าง ๆ เป็นอย่างไรบ้าง ?
  • เพื่อทำให้เห็นว่าชุดการทดสอบใดเหมาะกับการทดสอบแบบ maunal บ้าง ?
  • สามารถนำวิธีการ Automation testing มาช่วยทดสอบตรงไหนได้บ้าง ?
  • ทำการลบชุดการทดสอบที่ไม่จำเป็นออกไป
  • ทำการลบชุดการทดสอบที่ซ้ำซ้อนออกไป
  • ทำให้เห็นว่าชุดการทดสอบเป็นแบบ Data driven หรือไม่ ?
ตัวอย่างของการวิเคราะห์ automationtesting

2. ให้ทำการพิจารณา Test framework ที่เหมาะสมกับทีม

ในปัจจุบันเครื่องมือในการทดสอบ Mobile app แบบอัตโนมัติที่เป็น opensource นั้น มักต้องการคนที่มีความสามารถเรื่องการ coding ทั้งภาษา Java, Python, Ruby, C# และ JavaScript เป็นต้น ซึ่งเป็นสิ่งที่ขัดแย้งต่อทีมที่มีรับผิดชอบต่อการทดสอบคือ Tester/QA (Traditional) ทำให้การทดสอบแบบอัตโนมัติไปไม่ถึงไหน หรือ ไม่เกิดขึ้นเลย ดังนั้นการเลือกเครื่องมือก็ต้องให้เหมาะสมกับทีมเช่นกัน เช่นการนำ BDD และ SbE มาใช้ ซึ่งเน้นไปที่ business flow น่าจะเหมาะสมกว่า ส่วนความสามารถด้วย coding ก็ลดลงไป แต่ถ้าสามารถเพิ่มความสามารถด้าน coding ด้วยก็จะแจ่มมาก ๆ

3. เริ่มนำการทดสอบแบบอัตโนมัติเข้ามาอยู่ในการรอบการพัฒนาซะ

ถ้ายังทำการทดสอบในรูปแบบเดิมคือ รอให้จบการพัฒนาก่อนแล้ว เพียงแค่ทดสอบแบบ manual ก็ยังไม่ค่อยรอดเลย จะมีทำการทดสอบแบบอัตโนมัติยิ่งไปกันใหญ่ ดังนั้นสิ่งที่ควรจะต้องทำคือ นำการทดสอบแบบอัตโนมัติเข้ามาไว้ในการพัฒนาเลย เช่น
  • ทดสอบก่อนที่จะ checkin code เข้ามายัง source code repository
  • ทดสอบหลังจากที่ทำการ checkin code เข้ามายัง source code repository
ซึ่งวิธีการนี้จะบังคับให้ทีมพัฒนาและทดสอบต้องทำงานด้วยกัน พูดคุยกัน ถ้าทุกอย่างเป็นไปด้วยดีก็จะช่วยลดการทดสอบแบบ manual ลงไปได้มาก สุดท้ายแล้ว การทดสอบทั้ง manual และ อัตโนมัติยังร่วมกันต่อไป แต่เราจะทำอย่างไรเพื่อช่วยทำให้การทดสอบสนุกและเจ็บปวดน้อยลงไป Reference Websites http://blog.perfectomobile.com/automation/3-benefits-replacing-manual-testing-automation/

สรุปผลการสำรวจ The State Of JavaScript 2016

$
0
0

state-of-js

state-of-js จากการสำรวจเรื่อง The State of JavaScript 2016 นั้น โดยมีผู้ทำแบบสำรวจมากกว่า 9,000 คน ได้ผลลัพธ์ออกมาแล้ว น่าจะทำให้เห็นว่า Ecosystem ของ JavaScript ในปัจจุบันเป็นอย่างไรบ้าง ? น่าจะตอบคำถามได้มากพอควร เช่น
  • สถานะของ JavaScript เป็นอย่างไร ?
  • React vs Angular ?
  • ใช้ Redux ไหม ?
  • ใช้ Vue ไหม ?
  • ใช้ Elm ไหม ?
  • ใช้ Webpack ไหม ?
  • จัดการกับ CSS ยังไงดี ?
ดังนั้นมาดูผลจากแบบสำรวจในครั้งนี้กันนิดหน่อย

หัวข้อแรกคือ JavaScript Flavors

ผลที่ออกมาก็คือ ES6 เป็นมาตรฐานใหม่ที่ได้รับความนิยมสูงมาก ๆ ซึ่งสูงมากพอ ๆ กับ Plain JavaScript เลย ส่วนที่ตามมาห่าง ๆ คือ TypeScript และ CoffeeScript ส่วน Elm และ ClojureScript ก็มีบ้างนิดหน่อย สิ่งที่น่าสังเกตุคือ CoffeeScript เคยได้รับความนิยมสูง แต่ปัจจุบันกลับมีการใช้งานลดลง เนื่องจากมี ES6, TypeScript และ Elm เข้ามาแทนที่ js-01 เมื่อดูความสัมพันธ์กับเทคโนโลยีหรือ framework อื่น ๆ พบว่า ES6 นั้นจะสัมพันธ์กับ React, Redux, Webpack, Mocha, Enzyme อย่างแนบแน่น และ ES6 บ้าง แสดงดังรูป js-02 ส่วน TypeScript จะมีความสัมพันธ์กับ Angular/Angular2, Jasmine, MEAN stack และ ES6 บ้าง แสดงดังรูป js-08

หัวข้อสองคือ Front-end framework ที่ได้รับความนิยม

React นำมาเป็นอันดับ 1 ติดตามมาด้วย Plain JavaScript ซึ่งไม่ใช้ framework ใด ๆ เลย จากนั้นก็ Angular, Angular 2, Vue, Backbone และ Ember ที่แรงมาคือ Vue นั่นเอง เพราะว่า มีจำนวนการใช้งาน และผู้ที่กำลังเรียนรู้เยอะพอ ๆ กับ React และ Angular 2 เลย ถ้าดูในส่วนการเลิกใช้งานจะพบว่า การไม่ใช้ framework ใด ๆ มีจำนวนเยอะมาก เนื่องจากเริ่มมี framework ดี ๆ เข้ามาช่วยเยอะขึ้น พอ ๆ กันกับ Angular ซึ่งน่าจะเป็นเพราะ Angular 2 เช่นเดียวกับ Backbone ที่จำนวนเลิกใช้งานเยอะเหมือนกัน แสดงดังรูป js-04

หัวข้อสามคือ เรื่องการจัดการ State

ไม่ใช่เรื่องหลักหรือสิ่งที่จำเป็นเท่าไรนัก บางระบบอาจจะใช้หรือไม่ใช้ก็ได้ หัวข้อนี้หนีไม่พ้น Redux แน่นอน ตามมาด้วย Relay และ Mobx ซึ่งถ้าใช้ Relay ก็ต้องมาคู่กับ GraphQL นะ

หัวข้อสี่คือ API Layer

แน่นอนว่ายังคงเป็น REST API ที่ได้รับความนิยมสูงสุด โดยมี Firebase, GraphQL ตามมาห่าง ๆ แต่ตัวที่กำลังได้รับความสนใจมาก ๆ คือ GraphQL ซึ่งต้องดูกันต่อไปว่าจะเป็นอย่างไร js-05

หัวข้อห้าคือ Testing framework

เป็นสิ่งที่ขาดไม่ได้เลยในปัจจุบัน โดยสิ่งที่ได้รับความนิยมสูง ๆ คือ Mocha และ Jasmine ส่วนที่ตามมาห่าง ๆ คือ Enzyme, Jest, Cucumber และ Ava แสดงดังรูป js-06

หัวข้อหกคือ Build tool

เป็นสิ่งที่ขาดไม่ได้เลยสำหรับ JavaScipt สิ่งที่ได้รับความนิยมคือ Webpack และ Gulp ส่วนที่ตามมาคือ Grunt และ Browserify จะสังเกตุได้ว่าสิ่งที่ได้รับความนิยมจะสัมพันธ์กันคือ
  • Webpack จะถูกใช้จากระบบที่พัฒนาด้วย React + ES6
  • Gulp จะถูกใช้งานจากระบบที่พัฒนาด้วย Angular/Angular 2
แสดงดังรูป js-07

ปิดท้ายด้วยคำถามต่าง ๆ ที่น่าสนใจ

ปัจจุบันการสร้างระบบด้วย JavaScript นั้นมีความซับซ้อนเกินไปหรือไม่ ? ส่วนใหญ่ตอบว่าใช่ ซึ่งมันอาจจะเป็นปัญหาในอนาคตได้ Ecosystem ของ JavaScript มันเปลี่ยนเร็วมากหรือไม่ ? ส่วนใหญ่ตอบว่าใช่ บางครั้งเร็วมันก็ดี แต่บางครั้งก็ช้าบ้างก็ได้นะ แล้วคิดว่า JavaScript มันมีทิศทางที่ถูกต้องหรือไม่ ? ส่วนใหญ่ตอบว่าถูกต้อง สนุกกับการพัฒนาระบบด้วย JavaScript หรือไม่ ? ส่วนใหญ่ตอบว่ามาก สุดท้ายคิดอย่างไรกับแบบสำรวจครั้งนี้ ตอบเลยว่า แม่งยาวมาก ๆ สามารถอ่านบทสรุปแบบละเอียดได้ที่ The State of JavaScript 2016  

ทำความรู้จัก Yarn สำหรับจัดการ dependency ของ JavaScript

$
0
0

yarn-kitten-full

yarn-kitten-full Yarn คือ dependency management tool หรือ package manager สำหรับ JavaScript จากทีมพัฒนาของ facebook ซึ่งบอกว่าเร็ว และ ง่ายต่อการใช้งาน และสามารถ share code/package/module ให้คนอื่น ๆ ได้ด้วย ซึ่งมันมีความสามารถเดียวกับ NPM เลย

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

ก่อนอื่นต้องทำการติดตั้ง Node.js ก่อนนะ จากนั้นสามารถติดตั้งได้หลายวิธี (Installation) เช่น [code] $brew install yarn หรือติดตั้งผ่าน NPM ก็ได้ !! $npm i -g yarn [/code] จากนั้นลองใช้งานด้วยคำสั่ง [code] $yarn [/code] ถ้าเทียบกับ NMP มันคือ npm install นั่นเอง

เริ่มใช้งานนิดหน่อย ซึ่งไม่ได้ต่างกับ NPM มากนัก

[code] 1. สร้าง project $yarn init 2. ทำการเพิ่ม dependency/package/module $yarn add &lt;package name&gt; 3. ทำการ update dependency/package/module $yarn upgrade &lt;package name&gt; 4. ทำการลบ dependency/package/module $yarn remove &lt;package name&gt; 5. ทำการติดตั้ง dependency/package/module ของ project ซึ่งกำหนดในไฟล์ package.json $yarn หรือ $yarn install [/code]

ปัญหาก็ใช้ได้เลยเมื่อเปลี่ยนจาก npm มาเป็น yarn เช่น

การใช้งานกับ react-scripts ซึ่งทำการสร้างผ่าน create-react-app ในการจัดการ dependency ต่าง ๆ ไม่มีปัญหาอะไร แต่ปัญหาคือ หาไฟล์ script ที่อยู่ใน folder node_modules/.bin/ ไม่เจอ ซึ่งทำให้ไม่สามารถใช้งาน react-scripts ได้เลย !! เมื่อไปดูใน issue ของ yarn ก็พบว่ามีคนแจ้งไปแล้ว issue 1058

ในเรื่องของ performance เมื่อเทียบกับ NPM

ก็มีการแสดงผลให้ดูที่ Compare Yarn Performance ซึ่งให้ผลการทำงานที่รวดเร็วจริง ๆ และจากการลองใช้งานมันก็เร็วกว่าจริง ๆ นะ ส่วน feature อื่น ๆ ยังไม่ได้ทดลองมากนัก

ปิดท้ายด้วยการเปรียบเทียบชุดคำสั่งกับ NPM นิดหน่อย

ซึ่งมีชุดคำสั่งที่เหมือนกันมาก ๆ ดังนี้
  • npm init => yarn init
  • npm run => yarn run
  • npm test => yarn test
  • npm login => yarn login
  • npm link => yarn link
  • npm publish => yarn publish
  • npm cache clean => yarn cache clean

ว่าแล้วก็ลองใช้กันดูครับ

ยังคงไปดึง dependency ต่าง ๆ มาจาก NPM repository เหมือนเดิมนะ และยังมี dependency manager อื่น ๆ ให้ใช้อีกนะ
  • ied
  • pnpm
  • npm-install
  • npmd
ปล. ชื่อ Yarn มันอาจจะทำให้งงกับ Hadoop Yarn ได้ง่าย ๆ !! Reference Websites https://code.facebook.com/posts/1840075619545360/yarn-a-new-package-manager-for-javascript/ https://shift.infinite.red/npm-vs-yarn-cheat-sheet-8755b092e5cc#.4viy9qn2n

16 Programming language ที่ควรศึกษาไว้ เพื่อไม่ให้ตกงาน

$
0
0

coding-language

coding-language อ่านบทความเรื่อง Learn any of these 16 programming languages and you'll always have a job จาก BusinessInsider ทำการสรุป Programming Language ที่ developer ควรจะเรียนรู้ไว้ เพื่อเพิ่มโอกาสในการได้งาน ซึ่งมีความน่าสนใจดี มีทั้งภาษาเก่า ๆ จนถึงใหม่ล่าสุด ทั้งนี้มันขึ้นอยู่กับระบบของบริษัทนั้น ๆ ด้วยว่าพัฒนาด้วยภาษาอะไร โดยข้อมูลในบทความนำมาจากที่ต่าง ๆ ประกอบไปด้วย มาดูกันว่ามีภาษาอะไรบ้าง ?
  • Java เนื่องจาก ecosystem เยอะตั้งแต่ desktop, browser, mobile, IoT ดังนั้นความต้องการยังสูงมาก ๆ
  • C ถึงจะเก่าแต่ยังเก๋า เรื่องประสิทธิภาพไม่ต้องห่วง แต่หาคนที่เชี่ยวชาญได้ยาก ค่าตัวจึงสูงมากเช่นกัน
  • Python เป็นภาษาที่อ่านง่าย เข้าใจง่าย จึงทำให้ง่ายต่อการพัฒนาระบบ แต่ไม่แน่ใจว่าในประเทศไทยความต้องการเป็นอย่างไร ?
  • PHP เชื่อว่า developer จำนวนมากไม่ชอบ PHP เพราะว่ามีปัญหามากมาย แต่ว่าคงปฏิเสธไม่ได้ว่า ระบบ web ส่วนใหญ่ทั่วโลกยังคงพัฒนาด้วยภาษานี้ รวมทั้งประเทศไทยด้วยเช่นกัน
  • Visual Basic หลาย ๆ คนร้องยี้เมื่อได้ยิน แต่มีระบบมากมายที่ยังใช้อยู่ ถ้าเข้า 7-11 แล้วคุณจะเห็น รวมทั้งระบบ POS ต่าง ๆ
  • JavaScript ในปัจจุบันได้รับความนิยมสูงมาก ๆ ๆ จากเหล่า Front-end developer แต่ปัญหาที่ตามมาก็คือ ทำให้ browser ทำงานหนักและเสี่ยงต่อการโจมตีสูงขึ้น ในไทยมีความต้องการเยอะมากมาย
  • R ถามพูดถึงเรื่องสถิติ เรื่อง data analysis คงไม่มีใครไม่รู้จัก แน่นอนว่าความต้องการก็สูงมากด้วย เนื่องจากเรื่องของ Big Data มันแรงมาก ๆ
  • Go สร้างโดยทีมพัฒนาของ Google ทำให้ภาษามันง่ายและพร้อมต่อการขยายระบบอย่างมาก ที่สำคัญ community ของภาษานี้ก็โตวันโตคืนด้วยอัตราที่สูงเสียด้วย ส่วนในไทยเริ่มนำมาใช้พัฒนามากขึ้นเรื่อย ๆ
  • Ruby เป็นภาษาที่มีคุณลักษณะเช่นเดียวกับ Python เป็นภาษาที่สวยงามมาก ๆ แต่ในไทยกลับใช้งานไม่กว้างขวางนัก ส่วนความต้องการในไทยใช้ได้เลยนะ ถ้าคุณเข้าไปถูกบริษัท
  • Groovy ออกแบบมาเพื่อทำให้เขียน code น้อยลง ซึ่งยังสามารถทำงานบน JVM ได้ ใช้งาน library ต่าง ๆ ของภาษา Java ได้ ทำให้การพัฒนาง่ายขึ้น แต่ว่าในไทยกลับไม่ได้รับความนิยม แต่มี Scala ที่เริ่มได้รับความนิยมขึ้นมาแทน
  • Objective-C สำหรับการพัฒนา iOS app แล้วคงหนีไม่พ้น โดย app ส่วนใหญ่ยังคงเป็นภาษานี้ ถึงแม้ว่าภาษา Swift จะได้รับความนิยมก็ตาม เนื่องจากหลายบริษัทไม่ต้องการที่จะลงทุนพัฒนาใหม่ด้วยภาษา Swift หรอกนะ หรือถ้าจะเปลี่ยนก็ยังต้องการคนที่อ่าน code ในภาษา Objective-C อยู่ดี
  • Perl ถูกพัฒนาโดยทีมพัฒนาของ NASA ตั้งแต่ยุค 80 ผมเคยเขียนแค่ระบบเดียว ในปัจจุบันที่ไหนในไทยใช้กันบ้าง ?
  • Pascal ยังมีที่ไหนใช้หรือเปล่านะ ?
  • Delphi หรือ Object Pascal + GUI ยังมีที่ไหนใช้หรือเปล่านะ ?
  • Swift เป็นภาษาใหม่สำหรับการพัฒนา iOS app นั่นเอง ซึ่งด้วยตัวภาษานั้นอ่านง่าย เขียนง่าย และปัจจุปันเป็น opensource แล้วนะ ทำให้มีกลุ่ม developer กว้างขึ้นเยอะมาก ๆ
  • MATLAB สำหรับการคำนวณทางคณิตศาสตร์ และ image processing แล้วคงต้องใช้งานมาอย่างแน่นอน แต่ส่วนใหญ่จะใช้กันมากในสถานศึกษา และ นักวิจัยมากกว่า แต่ในปัจจุบันองค์กรต่าง ๆ เริ่มนำมาใช้งานมากขึ้น
ดังนั้น developer ลองถามตัวเองสิว่า ใน 16 ภาษานี้คุณมีความรู้ความเชี่ยวชาญในภาษาใดบ้าง ?

สวัสดี Appium 1.6.0

$
0
0

appium-00 เมื่อ 7 วันที่ผ่านมา Appium ได้ปล่อย version 1.6.0 ออกมา โดยใน version นี้ได้ทำการ update feature ต่าง ๆ ที่รอคอยดังนี้
  • XCUITest สำหรับ iOS 9.3 และ 10 สำหรับ iOS app
  • UI Automator 2 สำหรับ Android app
ทำให้สามารถทดสอบ iOS และ Android app ได้สะดวกมากยิ่งขึ้นนะครับ ติดตั้งกันเลย [code] $npm install -g appium [/code] ลองใช้งานนิดหน่อย [code] $ appium [Appium] Welcome to Appium v1.6.0 (REV 91a225eef156568a474deb8a8e99ca47a82b27fd) [Appium] Appium REST http interface listener started on 0.0.0.0:4723 [/code] อีกทั้งยังเพิ่ม feature ให้สำหรับทดสอบ Windows desktop application และ You.i TV อ่าน Release note เพิ่มเติมได้ ส่วน Appium Desptop ยังไม่ทำการ update นะ
Viewing all 2000 articles
Browse latest View live