มาดู 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. ปรับปรุงการดักจับข้อผิดพลาด

Windows 10 – Universal Windows Platform ขอลองซักนิด

เนื่องจากว่า Microsoft โปรโมทนักหนากับ Universal Windows Platform (UWP) ที่เมื่อเขียนแล้วสามารถนำไปรันบน Windows 10, Windows Phone, Xbox, etc.. ซึ่งน่าจะเป็นการพลักดันครั้งสำคัญของ Microsoft ในการสร้าง Eco System ให้กลับมาแย่ง Market Share อีกครั้ง

โดยส่วนตัวแล้วผมก็มีประสบการณ์กับ C# + WPF มาพอสมควรทำให้ปรับตัวได้ไม่ยาก และ  UWP น้ันมี Architect เดียวกับ WPF ในการทำ User Interface.

เริ่มจาก

  1. Install Visual Studio 2015 Community Editoin ซึ่งใช้งานได้ Free 🙂
  2. สร้าง Project ใหม่เป็นแบบ UWP

newproj

3. ไฟล์ที่ถูกสร้างมาจาก UWP project ก็คุ้นหน้าคุ้นตา MainPage.xaml อีกแล้ว..

default_files

4. ลองมาดู Project Properties..ก็พบว่าเราสามารถ target App ของเราได้ตาม Windows 10 Build version

project_prop

5. มาดูฝั่ง XAML กันบ้าง ซึ่งตัว code ที่ Visual Studio สร้างมาให้ก็เป็นแค่หน้าจอขาวๆ

xaml_code.png

6. พวก Default Controls ของโลก WPF ก็ยังมาอย่างครบครัน

system_controls

7. ลองใส่ Button ดูก็ลอง ลาก แล้วก็วางได้เลย

xaml_code2

8. ลอง Double Click ที่ Button Object เพื่อเขียน Code Behide กัน
ลอง โชว์ Message Box

private async void button_Click(object sender, RoutedEventArgs e)
{
var dialog = new MessageDialog(“Hey Windows Universal Platform app!”);
await dialog.ShowAsync();
}

9. Compile App ได้เลยแล้วลอง Click ที่ปุ่ม Button

App เราก็จะถูก Style ด้วย Windows 10 – WUP UI เป็นค่าเริ่มต้น

msgbox_run

10. ถ้าอยากลองเทสกับหน้าจอหลายๆแบบ ใน Visual Studio ก็มีให้ปรับตามนี้

screen_res.png

11. ลองมาดู output files ของการ compile กันครับ ผลออกมาคือ .exe และ พวก dependencies assemblies ทั้งหลาย

app_output

12. ลอง double click เพื่อรัน App2.exe ตรงๆกันดูครับ

อ้าว error! แล้วเราจะรัน app ของเรายังไงล่ะครับ….

runtime_err.png

13. ลองไป เมนู Deploy App ดู

deploy.png

14. หลังจาก Deploy เสร็จ App ของเราก็มาโผล่ที่ Start Menu นั่นเอง

startmenu

และเนื่องจากผมลองเขียน app ที่มี scope ชัดเจนนิดนึง เลยลองเขียน App อ่านเวปสุดฮิต
แน่นอน Pantip นั่นเอง 🙂

ซึ่งตอนนี้ทาง app ก็ยังไม่มีอะไรมาก แค่ ListView ที่ทำ Data Binding กับ List Object เอามา render บนหน้าจอได้รวมถึงได้ลองใช้ HTTP req ในการดึง Data จาก Pantip.

pnatipw

ท้ายที่สุดจากการทดลองของผม UWP app นั้นเริ่มต้นได้ไม่ยากสำหรับคนที่มีความคุ้นเคยกับ C# และ WPF ซึ่งผมคิดว่าคนที่เคยเขียน Windows Form ก็น่าจะปรับตัวได้ไม่ยาก รวมถึง Visual Studio ที่เป็น IDE ที่ค่อนข้าง Powerful จึงทำให้การเขียนโปรแกรมทำได้เร็วขึ้น

 

ทดสอบ C# ด้วย .NET Core บน OSX

สำหรับคนที่เขียน C# บน Windows ก็คงต้องอยากที่จะให้มันเขียนได้บน Mac หรือ Linux ใช่มั้ยครับ จริงๆแล้วก็มี Mono Framework ที่ตอบโจทย์อยู่แล้ว แต่ถ้าเราต้องการ Native Experience ล่ะ?

.NET Core อาจจะเป็นคำตอบ (มั้ง)

เนื่องจากผมอยากลองดูว่า .NET Core ที่เป็น Open Source ของ .NET Framework ที่ทาง Microsoft ประกาศไว้ช่วงต้นๆปีที่แล้วจะเป็นยังไง ผมก็เลยลอง Setup ดูบน Mac เพื่อทดสอบ

เริ่มต้นจากทำตาม link นี้ http://dotnet.github.io/getting-started/ ซึ่งทางเวปจะ detect ให้ว่าตอนนี้เรากำลังใช้ OS อะไรอยู่

สำหรับ Mac – OSX จะต้องโหลดไฟล์ .pkg เพื่อทำการลง dotnet compiler ลงบนเครื่อง

หลังจากลงเสร็จก็มาเริ่มต้นจากใช้ Termial

Screen Shot 2559-01-10 at 11.48.19 PM

ลองสร้าง new default project ผ่าน commandline “dotnet new”

Screen Shot 2559-01-10 at 11.49.50 PM

ลอง “ls” ดูไฟล์ที่สร้างขึ้นมาจะได้แบบนี้ ซึ่งประกอบด้วย

  1. NuGet.Config
  2. Program.cs
  3. project.json

Screen Shot 2559-01-10 at 11.51.06 PM.png

ลองรัน command ตามที่ Getting Started บอกถัดไป “dotnet restore” เพื่อทำการ restore หรือ download พวก assemblies/dlls/modules ที่ได้กำหนดใน project.json มาเพื่อใช้ในการ Compile ตัวโปรเจคของเรา

Screen Shot 2559-01-10 at 11.54.08 PM

หลังจาก restore พวก dependencies ของโปรเจคเราแล้วลองสั่ง  compile และ run กันด้วย “dotnet run”

!!!! Error…

Unhandled Exception: System.IO.FileNotFoundException: Could not load file or assembly ‘System.Console, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a’ or one of its dependencies. The system cannot find the file specified.

Screen Shot 2559-01-10 at 11.56.20 PM

ปัญหานี้ก็คือมาดูที่ไฟล์ Program.cs

Code โปรแกรมเรามีการเรียกใช้ Console.WritLine หมายความว่ามันมี Dependency กับ System.Console ทำให้ Compile ไม่ผ่าน

using System;

namespace ConsoleApplication
{
 public class Program
 {
 public static void Main(string[] args)
 {
 Console.WriteLine("Hello World!");
 }
 }
}

ทีนี้มาดูไฟล์ project.json

{
 "version": "1.0.0-*",
 "compilationOptions": {
 "emitEntryPoint": true
 },
"dependencies": {
 "NETStandard.Library": "1.0.0-rc2-23616"
 },
"frameworks": {
 "dnxcore50": { }
 }
}

เราต้องทำการเพิ่ม dependencies เพื่อให้โปรเจคนี้รู้จัก dlls อื่นมากขึ้นเช่น System.Console ดังนั้นแก้ไฟล์ประมาณนี้

{
 "version": "1.0.0-*",
 "compilationOptions": {
 "emitEntryPoint": true
 },
"frameworks": {
 "dnxcore50": { 
"dependencies": { 
 "System.Console": "4.0.0-beta-*", 
 "System.IO": "4.0.11-beta-*", 
 "System.Runtime": "4.0.21-beta-*" 
 }
 }
 }
}

ลองรัน “dotnet restore” อีกรอบเพื่อโหลด dlls มาใหม่ก็จะยัง Error!!! ถ้าใช้ OSX 10.11.2+

ที่นี้ลองมาใช้ command นี้แทนในการ restore

“dotnet restore –runtime osx.10.10-x64”

จากนั้นก็ลอง “dotnet run” ในที่สุด Hello World! ก็ออกมาแล้ว

Screen Shot 2559-01-11 at 12.29.49 AM

ลองเขียน C# บน mac ด้วย Mono

วันนี้ว่างๆครับ เลยลองทดสอบการเขียนโปรแกรมด้วย C# บน mac
เนื่องจากว่า C# นั้นพัฒนาจาก Microsoft ซึ่งแรกเริ่มเดิมทีนั้นทำมาเพื่อ Windows

โดยทางสถาปัตยกรรมแล้วโปรแกรมหรือแอฟที่พัฒนาด้วยภาษา C# นั้นต้องทำงานภายใต้ .NET framework

ซึ่งได้มี project ที่ชื่อว่า Mono พัฒนา .NET framework สำหรับ OS อื่นๆที่ไม่ใช่ Windows และเราจะใช้สิ่งนี้ในการรันโปรแกรม C# บน Mac ครับ

เริ่มต้นจาก download  Mono จาก http://www.mono-project.com/download/ ก่อนซึ่งตัวนี้จะเป็นโปรแกรมที่เอาไว้รัน .exe ที่ compile จาก C#

จากนั้นก็ไป download http://www.monodevelop.com ซึ่งเป็นเครื่องมือ (IDE) ที่ทำให้เราพัฒนาโปรแกรม C# ได้ง่ายขึ้น เช่น UI Design, Debugging และ อื่นๆ ซึ่งจริงๆแล้ว IDE ตัวนี้คือ Xamarin Studio นั่นเอง

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

1. Code ในส่วนของการสร้าง window เปล่าๆไม่มีอะไรมาก

Screen Shot 2558-12-13 at 12.29.59 PM

2. มาหน้า Designer ซึ่งทาง Xamarin Studio ก็มี ToolBox Panel ที่ทำให้เราเลือก Control มาวางที่ Window ได้เลยเหมือนที่ทำได้ใน Microsoft Visual Studio

Screen Shot 2558-12-13 at 12.47.20 PM

3. ทำการ handle event เวลาที่มีการ Click ปุ่ม แล้วแสดง Message Box

Screen Shot 2558-12-13 at 12.30.22 PM

4. ลองรันโปรแกรมดู ok เราได้ MessageBox กับข้อความที่ต้องการScreen Shot 2558-12-13 at 12.30.42 PM

เป็นการจบการ install และการทำ simple app อย่างง่ายดาย 🙂

 

 

ทักษะประจำกาย Developer #6 – Craftsmanship Developer นักพัฒนายอดฝีมือ

การเป็น developer ที่ดี นั้นไม่ใช่แค่ทำให้ software/program/app ทำงานได้ตามที่ user ต้องการ แต่ควรจะมีสิ่งที่มากกว่านั้น
แล้วสิ่งๆนั้นคืออะไรล่ะ?

Working Software นั้นอาจจะเพียงพอที่จะทำให้ปิดโปรเจคหรือส่งมอบให้ user ไปใช้งานได้ แต่ข้างในระบบนั้นอาจจะเต็มไปด้วย shortcut, hack, debt ต่างๆเต็มไปหมด ซึ่งเป็นสิ่งที่ไม่ควรสำหรับ Craftsmanship developer

ถ้าเราต้องการก้าวผ่านระดับ good developer ไปสู่ Craftsmanship developer สิ่งแรกที่ควรคิดถึงเลยคือ

well-crafted software – ก็คือ software ที่ออกแบบอย่างปราณีต,  code design สวยงาม เป็นระบบระเบี่ยบ อ่านง่ายและง่ายต่อการเข้าใจ

การจะสร้าง well-crafted software ได้นั้น ก็ต้องใช้ประสบการณ์และความทุ่มเท มากขึ้นแน่นอน
ผมว่าเราเริ่มจากแนวคิดง่ายๆก่อนเลยนะ

  • สมมุติว่าเราทำ implement จบไป 1 feature
  • ลองใช้เวลากับ code ที่เรา implement ไปซักพักนึง แล้วถามตั้งคำถามว่า …. “เราจะทำให้มันดีขึ้นยังไง”?
  • แล้วลองใช้เวลาอีกซักพักเพื่อแก้ไขสิ่งที่เรา implement ไป
  • ถ้าไม่พอใจก็ถามคำถามเดิมกับตัวเอง ว่า “มันน่าจะดีขึ้นได้อีกนะ?”
  • ผมเชื่อว่าการทำแบบนี้สม่ำเสมอจะทำให้ไปถึงจุดที่เรา implement สิ่งที่เรียกว่า well-crafted software ได้ในซักวันหนึ่ง

more info: http://manifesto.softwarecraftsmanship.org/

ทักษะประจำกาย Developer #5 – ไม่มีใครขายงานของเรา ได้ดีเท่าตัวเรา

เนื่องจากนิสัยโดยทั่วไปของ Developer ชอบคุยกับคอมพ์มากกว่ากับคน ทำให้ขาดทักษะในการพูดและการ Present

แต่ผมคิดว่า Present ให้เป็นนี่ล่ะ เป็นอีกหนึ่งจุดที่ทำให้เราก้าวผ่านขีดจำกัดของ Developer โดยทั่วไป

ผมดูทีวีแล้วก็ได้ยินประโยคนี้ “ไม่มีใครขายสิ่งที่เราทำ ได้ดีเท่าตัวเรา” ซึ่งผมก็เห็นด้วย 100% เพราะคนที่ทำควรจะต้องรู้จากข้อดีและจุดขายของสิ่งที่ทำไป แต่การที่จะนำเสนอสิ่งนี้ หรือพูดให้คนอื่นเข้าใจหรืออินตาม จะทำได้ยังไง นี่เป็นความท้าทายมาก

Developer โดยทั่วไปเวลาทำการขายของ(Present งาน) จะชอบการพูดถึง technology ที่ใช้ logic ที่เขียน และการเรียงลำดับขั้นตอนที่ไปๆมาๆ แล้วก็วนมาว่าเขียน Code อะไรไปบ้าง

คนฟังที่ไม่ได้อยู่ในพื้นฐานหรือทำงานด้วยกันมาอาจจะไม่เข้าใจและเกิดอาการหลุด..

ดังนั้นการขายของหรือการ Present งานสำหรับ Developer เราควรจะต้องรู้ว่ากำลังขายให้ใคร
เช่น การ Present งานให้กับ Stake Holders หรือว่า คนที่ไม่ใช่ technical เราควรจะเน้นที่ประโยชน์มากกว่ารายละเอียดการ Implement

ท้ายที่สุดจงจำไว้ว่า งานของเรา เราคือคนขายที่ดีที่สุด!!!

Classical Music – Air on the G String

ผมเป็นคนชอบฟังเพลง….หนึ่งในแนวเพลงที่ชอบก็คือ เพลงคลาสสิค
ถ้าพูดถึงเพลงที่คลาสสิคที่ฟังแล้วหวานๆ แน่นอนเราก็คือถึงแต่เพลง Canon

แต่ในที่สุดผมก็เจออีกหนึ่งเพลงที่คิดว่าฟังแล้วหวานกว่า Canon ซะอีก (สำหรับผมนะ)

ผมไม่มีพื้นฐานด้านการตีความเพลงคลาสสิค แต่หลังจากได้ฟังเพลงนี้ สื่งที่ผมนึกถึงคือ….ความโรแมนติก ซึ่งต้องพูดว่าเสียงไวโอลินมันเพราะบาดหูจริงๆ 😉

ทักษะประจำกาย Developer #4 – Eating your own dog food

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

แต่จริงๆเป็นการเล่นคำในวงการ software development ว่า การที่เราสร้าง Product อะไรมานั้น เราในฐานะผู้ใช้สร้าง ก็ควรจะใช้งานมันด้วย และที่สำคัญถ้าใช้ในชีวิตประจำวันได้เลยยิ่งดี ซึ่งแนวคิดนี้จะทำให้ Product/Software ที่พัฒนาออกมาได้รับ feedback ที่เร็วขึ้น รวมทั้งได้แง่มุมจากการใช้งานจริงของคนภายใน ก่อนที่จะส่ง Product ออกไปให้ User ใช้

แนวคิดนี้เปลี่ยนมุมมองของการพัฒนา software เลยนะ ผมว่า
เนื่องจากปกติแล้ว Developer จะชอบจดจ่อแต่กับการเขียน Code และเขียนให้เสร็จ แต่จะชอบละเลยการทดสอบ(Test) ซึ่งปกติ Developer จะ Test โดยสนใจผลลัพธ์ของ software ว่าทำงานถูกต้องรึเปล่า(ซึ่งนั่นก็เป็นข้อดี) แต่อีกมุมหนึ่งซึ่งเป็นหัวใจของการ Test ก็คือประสบการณ์ที่ดีของผู้ใช้ (User Experience)

ผมชอบแนวคิดนี้นะ จริงๆไม่ใช่เฉพาะแวดวง Software หรอกที่จะประยุกต์ไปใช้ได้ ผมว่ามันใช้ได้กับทุกผลิตภัณฑ์ เช่น

  1. ถ้าทำธุรกิจอาหาร คุณก็ควรจะกินอาหารจากฝีมือตัวเอง หรือ เซฟ ประจำร้าน อย่างสม่ำเสมอ เพราะถ้าคุณกินแล้วไม่อร่อย คุณคาดหวังจะให้คนอื่นกินอร่อยเหรอ?
  2. เซลล์ขายรถยี่ห้อ A ถ้าคุณเองดันใช้แต่รถยี่ห้อ B แล้วคุณจะแนะนำสิ่งดีๆ หรือประสบการณ์ดีๆจากรถยี่ห้อ A ได้ยังไง
  3. ถ้าคุณเปิดร้านกาแฟ แต่ตกเย็นคุณไปนั่งจิบกาแฟ s… แทนการชงเอง

ทั้งนี้และทั้งนั้น ก็อย่าลืมที่จะ Eating other dog food ด้วยนะครับ เพื่อเป็นการเปิดโลกและสร้างประสบการณ์ใหม่ๆ แล้วนำมาใช้กับชีวิตเรา 😉

ref: https://en.wikipedia.org/wiki/Eating_your_own_dog_food

ทักษะประจำกาย Developer #3 – Root Cause กับ Workaround?

คำ 2 คำที่คุ้นเคยมากสำหรับเราชาว developer

Root Cause ก็คือ ต้นตอของสาเหตุ
Workaround คือ การแก้ปัญหาอ้อมๆ เพื่อบรรเทาทุกข์

บ่อยครั้งที่ชีวิตในการทำงานของ Developer เราอาจจะหา Root Cause ไม่ได้ในเวลาที่จำกัดแต่เรารู้ว่าปัญหาคืออะไร เช่น

1. เรารู้ว่าการเขียน code แบบนี้มันแก้ปัญหาได้(มั้ง)แต่ไม่รู้ว่าเพราะอะไร นี่เป็นตัวอย่างนึงของ Workaround
2. ระบบของเราทำงานไป 2 วันแล้วทำงานช้าลง เราก็จัดการ restart เครื่องใหม่มันก็หายละ (แล้วอีก 2 วันมันก็ช้าอีก)  นี่เป็นตัวอย่างนึงของ Workaround โดนที่เราไม่ได้มองเลยว่าทำไมระบบทำไมถึงช้าลงได้

หรือยกตัวอย่างง่ายๆ เวลา TV ที่บ้านสมัยก่อนไม่ชัด เราทำไงกันครับ…ตบ TV ไป 2 ที ชัดเลย นี่แหละ Workaround!

การใช้ Workaround บ่อยๆ จะทำให้ทุกอย่างทับถมกันไปหมด จนสุดท้ายระบบก็เละและยากต่อการดูแล

การเป็น Developer ที่ดีเราควรจะหลีกเลี่ยง Workaround และเข้าใจกับ Code ทุกบรรทัดที่เขียนลงไป รวมทั้งการมองปัญหาที่ Root Cause เพื่อที่จะแก้ปัญหาได้อย่างถูกจุดและยั่งยืน ถึงแม้ว่าจะต้องใช้เวลาและความมุ่งมั่นมากกว่าก็ตาม…

ปลุกชีวิตอีกครั้งให้กับ 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 ปกติมันง่ายกว่ามาก
– และสุดท้าย ได้มือถือกลับมาใช้แก้ขัดได้อีกซักพัก 🙂