IDE หนึ่งในสิ่งพื้นฐานควรรู้ของ Developer

Developer คนไหนไม่รู้จัก IDE บ้าง? ถ้าคนๆนั้นเป็นคุณก็…..อ่านต่อเถอะครับ 🙂
ส่วนถ้ารู้แล้วก็ลองอ่านเล่นๆดูได้ครับ

IDE ย่อมากจาก Integrated Development Enviroment ซึ่งก็คือเครื่องมือที่ Developer ใช้ในการพัฒนา Software แบบครบวงจร เช่น Visual Studio, XCode, Netbean, Eclips, Xamarin และอื่นๆ

โดยความสามารถหลักๆ ของ IDE ผมขอแบ่งเป็น 4 อย่างใหญ่ๆละกัน

  1. Editor – เอาไว้เขียน Source Code รวมถึงพวก Syntax Hilight, Auto-Complete
  2. Compiler – เอาไว้ Build โปรแกรมจาก Code ไปเป็น Binary
  3. Debugger – เอาไว้ใช้ในการแก้หาวิธีในการแก้ Bug
  4. Tools – เครื่องมือช่วยต่างๆ เช่น Refactoring, จัดหน้าจอหรือ Visual Design, การทำ UML, ดู Database รวมถึงพวกทำ Static Code Analysis และการสร้าง Document จาก Code

มาถึงตรงนี้แล้วมีใครใช้ IDE ครบ 4 อย่างมั้ยครับ….จากประสบการณ์ของผมแล้วน้องๆ Developer  ส่วนใหญ่จะรู้จักมันในฐานะข้อ 1 และ 2 เท่านั้น

ซึ่งผมอยากแนะนำสำหรับคนที่ยังไม่ได้ลองใช้ความสามารถของ IDE ในการเป็น Debugger ควรจะหาเวลาไปเรียนรู้ไว้ครับ เพราะมันจะช่วยทำให้คุณแก้ Bug รวมถึงพัฒนา Feature ที่ซับซ้อนได้เร็วขึ้นจริงๆ

แต่ช้าก่อน…..ถ้าท่านที่สามารถทำงานกับโปรเจคขนาดใหญ่โดยไม่ต้องใช้ Debugger ได้ผมนับถือมากครับ แสดงว่า  Source Code น่าจะมี Unit Test ครบ 100% ซึ่งทำให้เจอBug ได้จาก Unit Test และไม่ต้องพึ่งการ Debug

นี่คือ Utopia of Software – Software ในอุดมคติเลย!

Canary Testing นกขมิ้นน้อยในเหมืองใหญ่

4_1278772155

เหล่าท่านๆ Engineer ทั้ง Developer และ QA อาจจะรู้ว่าการปล่อย Software ขึ้น Production ให้คุณลูกค้านั้นมีความตื่นเต้นเพียงใด ถึงแม้ว่าเราจะมีการหลายๆ Enviroment ในการพัฒนาระบบเช่น Development, Pre-Production, Production เพื่อลดความเสี่ยงลงแล้ว แต่ถึงอย่างนั้นตอนเอาขึ้น Production ก็ยังต้องลุ้นทุกที

เป็นปกติที่ระบบ Production ของ Software จะมีการ Config ที่แตกต่างกันกว่า Development อยู่เสมอ (แล้วทำไมมันไม่เหมือนกันล่ะ??) แต่ถ้าเราต้องอยู่ด้วยสถานะระบบแบบนี้เรายังมีทางออกนะครับ

สิ่งนี้เรียกว่า Canary Testing ซึ่งมาจาก Canary in Coal Mine มาจาก

การที่นักขุดเหมืองสมัยก่อนนั้นจะใช้นกขมิ้นในการทดสอบว่าเหมืองนั้นปลอดภัยไม่มีก๊าซพิษก่อนที่คนละทำการลงไปขุดในระดับที่ลึกขึ้น

การนำแนวคิดนี้มาใช้กับ Sofware ก็คือ เราจะให้กลุ่ม Users บางกลุ่มนั้นได้ลองใช้ Software Version ใหม่ก่อนคนอื่นๆ เพื่อป้องกันการความเสี่ยงจากการ Release ที่เดียว Impact ทุกคน หรือเรียกว่า BIG BANG Release
จากนั้นก็ค่อยๆรับ Feedback จาก Users กลุ่มๆนี้ ถ้ามี Critical Bug ก็ทำการแก้ไขก่อนที่จะเริ่ม Release ให้กับ Users ในกลุ่มที่ใหญ่ขึ้น และทำแบบนี้ไปเรื่อยๆจน Release ให้กับทุก Users

ถ้าระบบของ Software เราเป็น Web เราอาจจะทำ Canary Tetsing/Release ได้ง่ายขึ้นจากการ

  1. โดยอาจจะเริ่มจาก กลุ่มผู้โชคดี > ประเทศ > ทวีป > ทั้งโลก เป็น 4 ขึ้นตอน
    ซึ่งอาจจะทำได้โดย detect  ว่า Users มาจาก IP ช่วงไหนแล้วก็ Redirect ไปยัง URL ของ Version ใหม่
  2. ถ้ามีระบบ User อาจจะมี Option ว่าเป็น Early Accessได้ แล้วระบบเราเช็ค Flag นี้ในการตัดสินใจ Version
  3. สร้าง URL ใหม่เลยแล้ว Promote ที่ Banner ว่า Try Latest Version!

ซึ่งแน่นอนว่าการที่ระบบจะทำ Canary Testing ได้ก็ต้องลงทุนและต้องมีสถาปัตยกรรมที่รองรับ และยิ่งถ้าระบบใหญ่ๆและการ Release ทีนึงมี Impact กับ Users เยอะๆนี่ ผมว่าคุ้มนะ 🙂

Microsoft CEO – Satya ทำงานยังไง แล้วพวกเราล่ะ?

ทาง Wall Street Journal ได้ทำ clip 2-3 นาที ซึ่งเป็นการสัมภาษณ์คุณ Satya – CEO ของ Microsoft เกี่ยวกับวิธิการทำงานของเค้าเป็นการถามตอบสั้นๆที่ทำให้รู้จักตัวเค้ามากขึ้น

สิ่งที่ผมดูแล้วชอบเป็นพิเศษคือคำถามที่ว่า

How do you run a meeting? (คุณดำเนินการประชุมยังไง) ใน นาที 1.05

คุณ Satya ตอบได้กระชับมากว่า
Listen More,  Talk Less and be decisive when the time comes” – ฟังเยอะ พูดน้อยแเละเด็ดขาดเมื่อถึงเวลา

ผมรู้สึกถึงพลังของผู้นำที่มีพื้นที่ให้พนักงานได้มีโอกาสแสดงความคิดเห็น มากกว่ารอคำสั่งจาก Leader ซึ่งผมว่าดีมาก

อย่างไรก็ตามสำหรับ Engineer อย่างพวกเราผมว่า

Talk Less, Code more, Show working software”  😉

เห็นด้วยมั้ยครับ…

Hero Driven Development

วันนี้ผมจะเล่านิทานให้ฟัง….

กาลครั้งหนึ่งนานมาแล้ว ณ หมู่บ้านที่สงบสุขท่ามกลางชีวิตที่เรียบง่ายของชาวบ้านที่ใช้ชีวิตอย่างมีความสุข

Screen Shot 2559-06-26 at 6.33.21 PM.png

สิ่งที่ไม่คาดคิดก็เกิดขึ้น ได้มีมังกรวายร้ายปรากฏตัวขึ้นมาเพื่อทำลายหมู่บ้าน

Screen Shot 2559-06-26 at 6.33.52 PM

ชาวบ้านได้ตื่นตระหนกและทำการสวดอ้อนวอน

Screen Shot 2559-06-26 at 6.35.36 PM.png

ทันใดนั้นเองก็ได้มี คนๆนึงที่ใครๆก็เรียกเค้าว่า ฮีโร่ ปรากฏกายขึ้นมา พร้อมประกายแห่งความหวัง

Screen Shot 2559-06-26 at 6.37.02 PM.png

แน่นอนว่าด้วยความเก๋าของฮีโร่ + กำลังใจอย่างเต็มเปี่ยมของชาวบ้าน
เค้าก็จัดการมังกรร้ายได้อย่างง่ายดาย…

Screen Shot 2559-06-26 at 6.37.34 PM.png

ในที่สุดชาวบ้านก็กลับมาใช้ชีวิตอย่างมีความสุขเช่นเดิม

Screen Shot 2559-06-26 at 6.33.21 PM.png

HAPPY ENDING

(?)

นิทานที่ผมเล่าไปนั้นสามารถตีความให้เกี่ยวกับการพัฒนา Software แบบ Hero Driven Development ได้

ซึ่งนั่นก็คือ..ในทุกครั้งที่มีแหตุการณ์ไม่ปกติ เช่น ปัญหาร้ายแรง/critical bugs/server ล่ม  ทีมงานทุกคนในทีมก็จะเฝ้ารอให้มีคนใดคนนึงที่พวกเค้าเชื่อว่าเก่งที่สุดดังเช่นฮีโร่ จะออกมาแก้ปัญหานี้ให้พวกเค้า และพวกเค้าจะทำหน้าที่นั่งเชียร์ คอยหาขนม และให้กำลังใจอยู่ห่างๆ อย่างห่วงๆ(?)
และเมื่อปัญหานี้ได้ถูกแก้ไป ทีมงานก็กลับไปทำงานตามปกติจนกระทั่งจะเกิดเหตุการณ์นี้ขึ้นอีกในอนาคต….

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

ปัญหาเหล่านี้ไม่ใช่ปัญหาของฮีโร่แต่เป็นปัญหาของทีม!

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

และสุดท้ายหวังว่า เราจะสร้างหมู่บ้าน Super HERO ไปได้ด้วยกัน

เรียบเรียงจาก
http://carlokruger.com/?p=35
http://highlevelbits.com/2014/08/hero-driven-development.html

Final Fantasy X/X-2 HD Remaster กับ Windows architecture

พอดีได้ข่าวว่า Final Fantasy X ได้ทำการ Port มาลง PC ก็เลยลองเล่นดูครับ เพราะภาคนี้ผมเล่นตอน PS2 ได้ประมาณ 30-40% แล้วก็ไม่ได้เล่นต่อเนื่องจากติดทำ Project จบสมัยเรียน เลยขายเครื่องทิ้งไปเพราะกลัวเรียนไม่จบ 🙂

แต่ที่เขียนถึงวันนี้คงพูดถึงเรื่อง Windows architecture กันนิดหน่อย

สืบเนื่องมาจากว่า ผมเล่นเกมนี้ไปได้ประมาณไม่นานเช่น 10-20นาที โปรแกรมก็ Crash ซึ่งมาจากขั้นตอนที่ไม่แน่นอน หรือเรียกว่า Random Crash นั่นเอง

ซึ่งการ Crash ของ Application นั้นก็หมายถึงการที่โปรแกรมหยุดทำงานด้วยสาเหตุใดสาเหตุหนึ่งแล้วโปรแกรมก็เด้งออกอัตโนมัติทิ้งให้เราอึ้งไปหลายวิ..

As User

จากการที่เราเป็น End User ของเกมนี้ก็ แน่นอนครับ ติดปัญหาเราก็ต้องลองหาใน Google ดูก็ก่อนเลย ซึ่งก็พบว่ามีหลายๆคนเจอปัญหาเดียวกัน

http://steamcommunity.com/app/359870/discussions/0/364042063114641626/
http://steamcommunity.com/app/359870/discussions/0/364042262885080038/
http://steamcommunity.com/app/359870/discussions/0/364042262879682906/

ซึ่งผมลองทำตาม workaround ต่างๆแต่ก็ยังไม่สำเร็จ เล่นไปสักแป๊บนึงเกมก็เด้งออกมาอีกเช่นเคย

As Developer

แต่ด้วยความที่เราก็ Developer ผมก็ตัดสินใจลอง Investigate ปัญหานี้ดูด้วยตัวเอง

สิ่งแรกที่ผมเห็นคือเวลามัน Crash ตัวไฟล์ CoreDump.dmp จะถูกสร้างขึ้นมา

coredump.png

ลองเปิดด้วย Visual Studio เพื่อทำการ Analyze Dump ไฟล์ได้ข้อมูลน่าสนใจตามนี้

dumpinfo

  1. Process นี้เป็น x86 ก็คือ 32 Bits
  2. Crash ที่เกิดขึ้นมี Exception เกี่ยวกับ Virtual Address หรือ Virtual Memory นั่นเอง

พอรู้แบบนี้ผมก็ลองเปิด Process Explorer ดูเลยครับว่าเวลาเล่นเกมนี้ มันใช้ Memory ขนาดไหน ปรากฎว่า…

ชัดเจนครับแค่เปิดเกมมา Virtual Memory ก็1.9GB แล้ว

screen

memreach

นี่คือสาเหตุของปัญหานี้ครับ..เนื่องจากว่า เกม(Process) นี้ถูก Compile ด้วย 32 Bits ทำให้สามารถใช้งาน Memory Space ได้ 2^32 bytes หรือประมาณคร่าวๆได้ 4GB (4,000,000KB โดยประมาณ)

แต่เนื่องจาก Windows Architect นั้นได้ทำการแบ่ง Memory ไว้เป็น 2 ส่วนคือ Kernel space กับ Application space (User space) อย่างละ 2GB

ซึ่งง่ายๆก็คือ Applicatoin จะใช้ได้ 2GB เท่านั้น ทำให้ถ้าใช้เกินโปรแกรมก็จะ Crash (ถ้าจัดการไม่ดี)

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

Windows นั้นได้มี Feature ที่เรียกว่า Large Address Aware ซึ่งทำให้ Application สามารถใช้งาน Memory ได้มากกว่า 2GB นั่นเอง

Tool ตัวนี้คือ Editbin.exe ซึ่งติดตั้งมากับ Microsoft Visual Studio อยู่แล้วครับ

พิมพ์ไปเลยครับตามนนี้

editbin /largeaddressaware “D:\Games\Final Fantasy X\FFX.exe”

editbin.png

เราก็จะได้ FFX.exe ตัวใหม่ที่ทำการเปิด Feature Large Address Aware แล้ว และเมื่อลองทดสอบดู Process ของเกมนี้ก็สามารถใช้ Memory ได้เกิน 2GB แล้ว

final_mem

และสุดท้ายตั้งแต่ผมแก้มาก็เล่นได้ 4-5 ชั่วโมงได้ไม่เจออาการ Crash/Freeze อีกเลยครับ 🙂

 

English:

For english guys (if any), I found one potential workaround to solve the random crash/freeze issues on FFX HD Remaster on PC. I think the issue is around memory reach limit of 32 Bits process which is 2GB for application space(from totally 4GB  – kernel and app/user space) which FFX has been built as 32 Bits app.

so once you configured the game with high graphic settings. it uses higher memory and might be able to trigger the issue more eaiser.

we can use the tool called “editbin.exe” which is the small utility to allow us to change the flag of the process which is “/largeaddressaware” that can help to incrase the app/user space of memory up to 3/4GB based on OS. but at least it will be higer than 2GB as system default.

you can find “editbin” from Visual Studio.

and after I applied this flag. I can play the game for 4-5 hours for 2 days without any crash. hope this can help for some.

 

HAPPY GAMING…

Continuous Deployment ของ Netflix

หลังจากที่ได้พูดถึงการทำ Continuous Deployment (CD) ของ Instragram ไปใน บทความที่ผ่านมา (link)

มาคราวนี้ทาง Netflix ซึ่งเป็น บริษัทที่ให้บริการด้านดูหนังและซีรีย์ออนไลน์ที่มีสมาชิกกว่า 75 ล้านคน

ทาง Engineer ของ Netflix ก็ได้มาแชร์ข้อมูลเกี่ยวกับการ Build http://techblog.netflix.com/2016/03/how-we-build-code-at-netflix.html

เราลองมาดูกันครับ

Netflix นั้นมีหรือ Workflow ตามรูปนี้

pasted image 0.png

ซึ่งกล่องสีขาวคือ Process ของการทำงานจากซ้ายมือไปขวามือ ส่วนสีฟ้าคือ Tools ที่ใช้

ก่อนที่จะลงรายละเอียดแต่ละขั้นตอนทาง Netflix ได้เน้นย้ำไว้ว่าสิ่งที่สำคัญที่ทำให้ Solution นี้เกิดขึ้นมาได้นั้นมาจาก

  1. วัฒนธรรมของบริษัท : ซึ่งก็คือ ความอิสระและความรับผิดชอบ เพื่อที่จะเน้นย้ำให้ทุกคนนั้นได้คิดถึง Solution หรือ Tool ที่ดีที่สุดในการแก้ปัญหาต่างๆได้อย่างเหมาะสม ซึ่ง Tool ที่ดีนั้นควรจะต้อง Add Value และช่วยลดขั้นตอนการทำงานด้วย ซึ่งทาง Engineers นั้นสามารถคิดหา Solution ได้เสมอและต้องคำนึงถึงการดูแลระบบด้วย
  2. Cloud : ทาง Netflix นั้นได้ทำการย้ายระบบจาก Data Center based ไปใช้ Amazon Webservice แทน
  3. Microservices : Netflix ได้เปลี่ยน architecture จากการทำงานด้วยระบบขนาดใหญ่ (monolithic) ไปเป็น Microservices แทน ซึ่ง Microservices นั้นคือการออกแบบให้ Services หรือ API นั้น เล็ก ไม่ซับซ้อน และเป็นอิสระต่อกัน เพื่อที่จะได้แก้ไขแต่ละ Service ได้ง่ายขึ้น

เริ่มจาก

  • Code ทำการ build และ test บนเครื่องของ Developer โดยใช้ Nebula (Tools ของ Netflix เอง)
  • Code Check-in : การ Commit Code เข้า Master branch โดยใช้ Git
  • Continuous Integration : ใช้ Jenkins ในการสั่งให้ Nebular ทำงาน ซึ่งสิ่งที่เกิดขึ้นในขั้นตอนนี้จะประกอบด้วย การ build, test, และการทำ package ที่ไว้ใช้สำหรับการ deploy
  • Bake : ในการ deploy ของทาง Netflix นั้นจะเริ่มจากการ สร้าง Image ของเครื่องใหม่บน Amazon  โดย Image นั้นได้มีการติดตั้งระบบพื้นฐานไว้แล้วเช่น Linux, มี Tools หรือ services ต่างๆพร้อมที่จะใช้สำหรับการติดตั้ง package ใหม่
  • Deployment (Deploy จนถึง Live) : ทาง Netflix ใช้ Spinnaker ช่วยในการทำ pipeline ในการ deploy ต่างๆเช่น เครื่อง Test การจัดการเกี่ยวกับการ deploy หลายๆทวีปพร้อมกัน การทำ canary release เพื่อให้ users ทดลองใช้

สุดท้ายนี้ Netflix ยังได้พูดถึงความท้าทายที่ทางทีมกำลังแก้ไขด้วย เช่น

  1. ปัญหาด้าน dependnecies ของ Java ซึ่งทางทีมก็ได้ปรับปรุงให้ดีขั้นแล้ว
  2. ขั้นตอนของ Bake ให้เวลาเยอะไป ซึ่งปัจจุบันขั้นตอนหลังจาก Code Check-in จน Deploy เสร็จนั้นใช้เวลา 16 นาที แต่เวลา 7 นาทีนั้นใช้ในขั้นตอน Bake ซึ่งเป็น 44% ของเวลาทั้งหมด

มาดู Continuous Deployment ของ Instagram กัน

เมื่อต้นเดือนเมษายน ทาง Engineer ของ Instagram ได้เขียนบนความของการทำ Continuous Deployment ภายในระบบของเค้า http://engineering.instagram.com/posts/1125308487520335/continuous-deployment-at-instagram

เราจะมาดูกันว่ามีอะไรน่าสนใจบ้าง [ผมแปลแบบสรุปไปด้วยนะครับ ดังนั้นอาจจะไม่ใช่การแปลแบบแป๊ะๆ]

ทำไปทำไม?

Continuous Deployment นั้นมีข้อดีมากมายๆนะครับ ใครไม่รู้จักคำนี้และทำงาน Software Development ที่มีระบบขนาดกลาง/ใหญ่ (ที่มี Developers มากกว่า 10 ละกัน) ควรจะลองศึกษาดู

  1. ทำให้ Developers/Engineers ทำงานได้เร็วขึ้น สามารถที่จะแก้ไขอะไรได้รวดเร็วมากขึ้น
  2. ทำให้ช่วยในการหาข้อผิดพลาดที่เกิดจากการแก้ไขตัวระบบได้เร็วขึ้น จากที่จะต้องมาดูสิ่งที่แก้ไขที่มีเยอะแยะ ก็มาดูแค่รายครั้งที่มีการ Deploy ในแค่ละครั้ง
  3. สิ่งที่ Commit แล้วมีปัญหาก็จะเจอได้รวดเร็วและยังแก้ได้เร็วด้วย

การนำไปใช้

ทาง Instagram นั้นใช้วิธี iterative approach ก็คือไม่ใช้ว่าทำระบบที่เดียวเสร็จแล้วใช้งานทันที แต่จะใช้การค่อยๆพัฒนาทีละจุดไปเรื่อยๆจนกระทั่งเสร็จสมบูรณ์

ก่อนหน้านี้เป็นยังไง

ก่อนที่ทาง Instagram จะมี Continuous Deployment นั้น Engineer จะใช้การ Deploy ตามใจและเวลาที่จะมีการแก้ไข รวมถึงต้องรู้การเช็ค Log และเริ่มการ Deploy ที่ละเครื่องเพื่อทำการทดสอบก่อนที่จะ Deploy ไปที่เครื่อง Servers ที่เหลือ

การทดสอบ/เทส

เริ่มจากการเพิ่มการเทสซึ่งเป็น Script ง่ายๆที่ทาง Engineer ต้องทำจากที่ต้องทำบนเครื่องที่ตั้งใจจะลงบน Production ก็เปลี่ยนมาเป็นทำการ Deploy ที่เครื่อง Canary Machine(เครื่องสำหรับให้ users ทดลองใช้)

จากนั้นมีการสร้างเครื่องที่ทำการทดสอบจาก Git – Master โดยใช้ Jenkins เมื่อเทสของ version ไหนผ่านก็จะมีการแนะนำว่าควรใช้ version นั้นแทนที่จะเป็น version ล่าสุด

การทำงานอัตโนมัติ

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

  1. จะเอา version ไหนไปใช้ในการ Deploy – ซึ่งทาง Instagram ก็เลือกใช้ version ที่ผ่านการทดสอบและมีการเปลี่ยนแปลงไม่เกิน 3 commits
  2. การ Deploy สำเร็จหรือไม่ – หลักการก็คือถ้าไม่สามารถ Deploy ไปที่ servers ได้ด้วยอัตรา 1% จะถึงว่าไม่สำเร็จ

ปัญหา

หลังจากที่ทาง Instagram ได้ทำมาก็พบว่ามีปัญหาใหญ่ๆคือ

เทสไม่ผ่าน

หลายๆครั้งที่ทาง Engineer ได้พบว่ามีการแก้ไข software ที่ทำให้การเทสไม่ผ่าน ซึ่งทำให้ไม่สามารถ Deploy ได้ ซึ่งการแก้ไขนั้นต้องทำการ revert แบบ Manual รวมถึงการเทสที่ใช้เวลานานและไม่ค่อยเสถียร ซึ่งทาง Engineer ก็ได้ทำการแก้ไขให้เทสได้เร็วขึ้นเป็น 5 นาทีจาก 15 นาที

สิ่งที่จะ Deploy

ทาง Instagram พบว่าสิ่งที่จะต้อง Deploy มีมากในคิว เนื่องจากว่าระบบ Canary สามารถดักจับปัญหาได้(ทั้งปัญหาจริง และบั๊ก) ซึ่งทำให้การ Deploy หยุด และต้องมีการแก้ไขด้วย Engineer เพื่อให้ระบบ Automation ทำงานต่อได้ ซึ่งทำให้เกิดการล่าช้าของการ Deploy สิ่งใหม่ๆ ซึ่งทาง Engineerได้แก้ไขปัญหานี้ด้วยการปรับปรุงเงื่อนไขในการทำ Automation deploy ให้ทำงานได้ดีมากขึ้น

หลักการที่แนะนำ

ทาง Instagram ยังได้แนะนำว่าถ้าอยากได้ระบบแบบของเค้า ให้ลองตามนี้

  1. การเทส

    ระบบเทสต้องเร็วและครอบคลุม แต่ไม่จำเป็นต้องสมบูรณ์ และต้องถูกใช้งานบ่อยๆ ทั้งตอน Code Review, ก่อนการ Deploy และหลังจาก Deploy

  2. Canary

    ต้องมีการทำ automated canary เพื่อที่จะป้องกันไม่ให้มีการ commit ที่ไม่ดีเข้าไปอยู่ในสิ่งที่จะ Deploy ลงบน Server ทุกเครื่อง

  3. Automated Test สำหรับการทำงานปกติ

    ไม่จำเป็นต้องมี automate ทั้งหมด แต่เฉพาะสิ่งที่สำคัญจริงๆและเป็นสิ่งที่เกิดขึ้นในเหตุการณ์ปกติ

  4. ทำให้คนรู้สึกมั่นใจ

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

  5. คิดไว้เลยว่าต้องเจอการ Deploy ไม่สำเร็จ

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

ขั้นต่อไป

  1. ทำให้เร็วยิ่งขึ้น
  2. เพิ่ม Canary
  3. เพิ่มข้อมูล
  4. ปรับปรุงการดักจับข้อผิดพลาด

ปลุกชีวิตอีกครั้งให้กับ Motorola Razr (xt910)

เรื่องของเรื่องคือเมื่ออาทิตย์ก่อน ผมอยากลอง flash รอมจาก Official Rom – Android 4.1.2 ไปใช้ CyanogenMod 12 (Lollipop 5.1) แต่ว่าพลาดครับ ดันไปลบ Partition หลักของรอมทำให้เปิดเครื่องไม่ได้ แล้วจะติดอยู่ที่โหมดพิเศษเรียกว่า AP fastboot

ความซวยบังเกิดเนื่องจากไม่ได้ชาร์จแบตเอาไว้มาก ทำให้ลองแก้อยู่ 2 ชั่วโมงแล้วแบตเริ่มจะหมด

ผลก็คือ โหมด AP fastboot ดันเช็คว่าถ้าแบตใกล้หมดมันจะไม่ให้ flash rom จบกันครับทำให้ผมต้องกลับไปใช้มือถือรุ่นเทพในอดีตซึ่งเป็นเครื่องสำรอง – Nokia E51

การที่อยู่ในโหมด AP fastboot นั้น ตัวระบบของ Motorola จะไม่ทำการชาร์จไฟเข้าเครื่องด้วยสาย USB ปกติ ซึ่งจริงๆผมก็ลองชาร์จดู 3-4 ชั่วโมง ไฟก็ไม่เข้าจริงๆ ณ จุดๆนี้ โทรศัพท์เครื่องนี้กลายเป็นที่ทับกระดาษไปแล้วพร้อมลายสวยๆเป็นหุ่นกระป๋องนอนแอ้งแม้ง

IMG_3243
ณ เวลานี้ผมมีทางเลือก 3 ทางสำหรับเครื่องนี้
1. ชาร์จแบตตรงๆจากสายไฟ แล้วต่อเข้าขั้ว+,- ที่แบตเอง
2. หาสาย Factory Cable มา เพื่อที่จะ by pass การเช็คแบตในโหมด Ap fastboot
3. ทิ้ง….รอซื้อเครื่องใหม่

พอนั่งศึกษาไป วิธีแรกไม่กล้าต่อแบตตรงครับกลัวเครื่องระเบิด ส่วนรอซื้อเครื่องใหม่ตอนนี้อยากลอง windows 10 ซึ่งยังไม่ออก
ผมเลยมาทางวิธีที่ 2 คือการทำสาย Factory Cable

สาย Factory Cable นั้นเป็นการแก้ระบบการส่งไฟจากสาย Micro USB เพื่อเพิ่มกระแสไฟให้กับ Pin ที่ไม่ได้ใช้ใน Micro USB ปกติ
ดูจากรูปด้านขวาก็คือการ จั้มสายจาก สายสีแดง #1 ไปเชื่อมกับ Pin #4 ที่ไม่ได้ใช้งานในรูปด้านซ้าย

สิ่งที่ต้องมีคือ
– สาย Micro USB
– หัวแร้งบัดกรี (ผมซื้อมา 160 บาท)
– ตะกั่วบัดกรี
– คีม มีด สำหรับการงัดแงะ

เนื่องจากว่านี่เป็นการบัดกรีครั้งแรกในชีวิตของผม ผลก็คือ…… สาย Micro USB เสียไป 1 สายพร้อมกับซากการแงะ จริงๆตอนแรกเหมือนจะใช้ได้ แต่พอขยับสายไปๆมาๆ สายเส้นอื่นๆที่ผมไม่ได้ยุ่งก็ขาดแล้วไม่สามารถกู้ได้เนื่องจากไปบัดกรีพลาดจนพลาสติกมันละลาย

IMG_3271

แต่เราต้องสู้ต่อไปเลยไปหาสาย Micro USB มาอีกสาย แล้วผลของความมุ่งมั่นก็สำเร็จ

IMG_3272 IMG_3273
และในที่สุดผมปลุกชีพ Motorola Razr ได้แล้วววววว

IMG_3269

สิ่งที่ผมได้จากการ workshop การซ่อมเครื่องครั้งนี้มีเยอะเลยครับ
– ได้ลองทำอะไรใหม่ๆ ที่ไม่เคยทำ ผมเรียนวิทยาการคอมพิวเตอร์มาซึ่งไม่ได้มีโอกาสทำพวกไฟฟ้าหรือวงจรเลย แต่การลองครั้งนี้ก็สำเร็จ
– กล้าตัดสินใจ ตอนนั่งกรีดสาย Micro  USB ที่มันใช้ได้อยู่ก็เสียดายนะครับ ถึงจะเส้นละ 200-300  ตอนทำเส้นที่ 2 เลยต้องรอบคอบกว่าเดิมเยอะ
– และ ความรู้เรื่องระบบ Architect ของ Android OS ที่ได้ตอนการ flash rom จาก AP Fastboot mode ที่ปกติตอน flash rom จาก mode ปกติมันง่ายกว่ามาก
– และสุดท้าย ได้มือถือกลับมาใช้แก้ขัดได้อีกซักพัก 🙂

เพลงประกอบในเกม…สิ่งที่ทำให้เกมเป็นมากกว่าความสนุก

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

มาดูกันว่าแต่ละเพลงที่ผมชอบมีอะไรบ้าง (ไม่ได้เรียบลำดับนะครับ) 🙂

1. Nier – Ashes of Dreams

เพลงจากเกม Nier ที่เนื้อหาของเกมก็ดูมืดหม่น ชื่อเพลงก็ฟังดูแล้วก็จะเศร้าแปลว่า “เถ้าถ่านของความฝัน” แค่อินโทรด้วยเสียงเปียโนและเนื้อเรื่องภาษาฝรั่งเศสที่ผมฟังไม่ออกแต่ก็รู้สึกว่าเพราะและเศร้า

2. Xenoblade Chronicles – Main Theme

เพลงเปิดเกมที่เริ่มบรรเลงตอน Title ที่ผมเปิดครั้งแรกตอนเล่นเกมนี้ครั้งแรกก็ทำให้ต้องเปิดค้างไว้แล้วฟังเพลงจนจบไป 3 รอบก่อนจะได้เข้าเกมครั้งแรก
แบบว่าฟังครั้งแรกก็ประทับใจกับความเพราะแบบไม่มีเงื่อนไขเลย…

เปียโนกับไวโอลิน ช่างเป็นอะไรที่เข้ากันได้จริงๆ

3. Granado Espada – Granado Espada theme

เพลงเปิดเกม Online ยอดฮิตอีกเกม ส่วนตัวแล้วผมไม่เคยเล่นเกมนี้เลย แต่เคยเห็นภาพตัวอย่างแล้วสนใจดีเลยเปิด youtube ไปดูแล้วก็พบว่า เพลงเค้าแต่งไม่ธรรมดาจริงๆ

เนื่องจากว่า Theme ของเกมนี้จะออกแนวยุโรปยุคเรเนซองค์และบารอค ทำให้เพลงจะมีกลิ่นอายของแนวคลาสสิค
และแน่นอนเพลงนี้ก็เปียโนมาซะหวานเลย

4. The Last Story – Main Theme

เพลงเปิดอีกแล้ว กับ 1 ในสุดยอดเกม RPG ส่งท้ายเครื่อง wii
เพลงเปิดเกมของเกม RPG ส่วนมากจะเน้นแนวๆ เศร้าๆและดู EPICๆ ซึ่งผมล่ะชอบจริงๆ

5. The Legend of Zelda: Skyward Sword – Ballad of the Goddess

บทเพลงแห่งเทพธิดา เพลงประจำเกม Zelda ของภาคนี้ ที่ฟังแล้วรู้สึกฮึกเฮิมและ EPIC มากๆ

ว่าด้วยเรื่องการเพิ่ม Productivity ของ Developers

หลายๆคนอาจจะเคยได้ยินคำว่า Productivity ถ้าแปลตรงตัวเป็นภาษาไทยก็แปลว่า “ความสามารถในการผลิต”
แล้วการเพิ่ม Productivity คืออะไรในแง่ของการพัฒนา software

ผมคิดว่าหน้าที่ของ Software Engineer, Software Developer, Programmer(เรียกรวมๆว่า Developer ละกัน) ก็คือการทำให้ software ที่เป็นไอเดีย สามารถออกมาเป็น Program หรือ App ที่มันทำงานได้จริงอย่างมีประสิทธิภาพ

การที่เหล่า Developer นั้นต้องมานั่งหน้าคอมแล้วทำงานที่ไม่เกี่ยวกับการพัฒนา software สิ่งเหล่านั้นเราควรจะคิดว่ามันเป็นสิ่ง developer ไม่ควรจะเสียเวลาด้วยหรือควรจะเสียเวลาให้น้อยที่สุด ยกตัวอย่างเช่น การประชุมโดยที่ developer ไม่มีส่วนร่วม, การทำงานเดิมๆซ้ำๆ หรือแม้กระทั่งการ copy files ทุกวัน วันละ 2-3 รอบแล้วต้องนั่งรอ

ยกตัวอย่างเช่นถ้างานทุกวันของ Developer คือการ compile source code ที่ให้เวลา 10 นาทีต่อการ compile 1 ครั้ง
วันนึง Developer ต้อง compile ประมาณ 10 รอบ หมายความว่าในแต่ละวัน Developer จะเสียเวลา compile ไป 100 นาที = 1.5 ชม กว่าๆ

ถ้า Developer มีเงินเดือน 30,000 บาท หรือประมาณ 1,500 บาทต่อวัน ( นับ 20 วันทำงาน ) หมายความว่าเราอาจจะเสียเวลาของ Developer ใช้ในการ compile code ประมาณ 300 บาทต่อวัน หรือ 6,000 บาทต่อเดือน

ถ้าเราเอาเงินจำนวนนี้มาอัพเกรดเครื่อง Computer ให้ Developer เพื่อที่จะลดเวลาจาก 10 นาทีเป็น 5 นาที หมายความว่าเราจะมีเวลาให้ developer ใช้ในการทำงาน(เขียนโปรแกรม หรือ ออกแบบระบบให้ดีขึ้น) ซึ่งจะมีประโยชน์มากกว่าการรอ compile….