อย่าไว้ใจเว็บแบรนด์ระดับโลกให้เก็บรหัสผ่านที่สำคัญของคุณ

จากกระทู้ต้นเรื่อง Starbucks Thailand ทำแบบนี้ได้ไง

ผมเลยลองทดสอบดูตามข้อมูลที่ https://www.starbuckscard.in.th/cards/forgot-password.aspx

2014-03-04_101523แล้วกรอกอีเมลที่ตัวเองได้ลงทะเบียนไว้แล้วพบว่ารหัสผ่านที่ส่งมานั้น ทาง Starbucks ส่งมาเป็น plaintext จริงๆ ตามข้อมูลด้านล่างนี้ (ผมขอนำรหัสผ่านจริงๆ ออกเพื่อประกอบการนำเสนอ และใส่ข้อความอื่นๆ แทน)

2014-03-04_101432แน่นอนว่าไม่ใช่แค่เว็บเท่านั้น เมื่อเกือบ 2 เดือนที่แล้ว Starbucks ก็ได้ทำพลาดแม้แต่ใน App ของตัวเองใน App Store เช่นกัน ตามรายการข่าวบางส่วน เช่น Starbucks: We Stored Your Passwords in Plaintext หรือ Starbucks App Saves Usernames, Passwords in Plain Text 

ซึ่งในความเป็นจริงแล้ว ระบบเว็บ หรือซอฟต์แวร์ต่างๆ โดยทั่วไปที่ใส่ใจต่อข้อมูลรหัสผ่าน ซึ่งเป็นข้อมูลที่อ่อนไหวง่ายที่สุด มักจะนำรหัสผ่านผู้ใช้งานไปผ่านกรรมวิธี hash ทางเดียว (one-way hashing; หรือลายเซ็นของข้อมูล) และใช้ salt ร่วมด้วย (ชุดอักขระสุ่มเฉพาะ) เพื่อความปลอดภัยสูงสุด การที่เว็บแบรนด์ดังจัดเก็บรหัสผ่านแบบ plain text หรือแม้แต่จัดเก็บแบบเข้ารหัสแต่สามารถย้อนกลับรหัสผ่านใดๆ ให้เป็น plain text ได้ ถือเป็นเรื่องที่ยอมรับไม่ได้ในวงการ Security ในด้านระบบยืนยันสิทธิ์ในการเข้าใช้ระบบ โดยสำหรับใครที่ไม่เข้าใจกรรมวิธี hash และใช้ salt ร่วมด้วย แนะนำให้อ่าน Hash: ไม่รู้ว่ามันคืออะไรแต่มันใช่ เผื่อจะเข้าใจมากขึ้น ว่าสิ่งที่ Starbucks กำลังทำอยู่นั้นเป็นสิ่งที่ยอมรับไม่ได้ และสามารถดูตัวอย่างเว็บที่ไม่ใส่ใจกับข้อมูลอ่อนไหวเหล่านี้ได้ที่ Plain Text Offenders

ฉะนั้นจากเหตุการณ์นี้ หลายคนอาจจะยังไม่เข้าใจปัญหาที่อาจจะเกิดขึ้นในอนาคต ผมจึงขอยกตัวอย่างง่ายๆ ว่าในอนาคตหากเว็บ Starbucks ถูก hack และเหล่าผู้ไม่ประสงค์ดีได้ทำการ dump ข้อมูลลูกค้าพร้อมรหัสผ่านออกไป การไม่คงสภาพรหัสผ่านที่สามารถย้อนกลับมาเป็น plain text ได้ จะช่วยปกป้องให้รหัสผ่านต่างๆ ของลูกค้าของตัวเองยังคงปลอดภัยอยู่สักระยะจากการใช้วิศวกรรมย้อนกลับ เพราะต้องใช้เวลาในการคำนวณ และกู้สภาพย้อนกลับผ่าน rainbow table (หรือการทำ rainbow hash cracking) แน่นอนว่าการใช้ salt ร่วมด้วยก็ช่วยได้ในระดับที่น่าพอใจ ซึ่งดีกว่าการจัดเก็บรหัสผ่านเป็นข้อมูล plain text ซึ่งผู้ไม่ประสงค์ดีสามารถนำไปใช้ได้เลยโดยไม่จำเป็นต้องใช้เทคนิคพิเศษใดๆ

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

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

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

มาทำความรู้จัก MariaDB Galera Cluster ในเบื้องต้น

เป็น note ที่เขียนไว้นานแหละ แต่ draft ไว้ไม่ได้โพส เลยมาโพสสรุปสักหน่อย

MariaDB Galera Cluster เป็น Synchronous replication แบบ master-master replication (Active-active multi-master topology) ต้องใช้ Server จำนวน 3 เครื่องขึ้นไปในการทำงาน โดยความสามารถของ MariaDB Galera Cluster นั้น เป็นการช่วยเสริมความมั่นคง และเหมาะกับระบบที่เน้นข้อมูลที่มีการเปลี่ยนแปลงอยู่บ่อยครั้ง เพราะจากแต่เดิมนั้น เรามักใช้ MySQL หรือ MariaDB ในรูปแบบ standalone server แบบเดิมๆ ซึ่งอาจจะปรับไปใช้รูปแบบโครงสร้างที่ชื่อว่า Asynchronous replication (master-slave replication) โดยรูปแบบดังกล่าวมีข้อเสียในด้านความมั่นคงของข้อมูลที่ master server ที่ใช้เพื่อ เพิ่ม ลบ และเปลี่ยนแปลงข้อมูล ที่มีเพียง server ตัวเดียวที่ทำงานเหล่านี้ได้ และมักเน้นหนักไปที่การอ่านข้อมูลมากกว่าการเปลี่ยนแปลงข้อมูล ซึ่งอาจเกิดเหตุการณ์ที่ทำให้ master server หยุดทำงานไป มีผลทำให้ไม่สามารถ เพิ่ม ลบ และเปลี่ยนแปลงข้อมูลได้ ทำให้การให้บริการเต็มรูปแบบนั้นหยุดลง ด้วยเหตุผลดังกล่าว เราจึงจำเป็นต้องหาแนวทางที่ชื่อว่า Synchronous replication หรือ multi-master replication (Active-active multi-master topology) ของ MariaDB Galera Cluster โดยต้องทำการย้ายฐานข้อมูลจาก MySQL หรือ MariaDB ในรูปแบบ standalone server หรือใช้รูปแบบโครงสร้าง Asynchronous replication (master-slave replication) ไปใช้ MariaDB Galera Cluster เพื่อใช้ในการแก้ไขปัญหาดังกล่าว

จุดสำคัญของตัว MariaDB Galera Cluster คือ มันสามารถอ่าน และเขียนได้จาก cluster node ใดๆ ก็ได้ โดยที่มีระบบ membership control สามารถปลดออกจากกลุ่มเมื่อพบความผิดพลาด หรือเพิ่ม cluster node อัตโนมัติเมื่อมีการเพิ่มเข้ามาในระบบ โดยข้อมูลในการจัดการภายในเป็นแบบเป็น parallel replication ระดับ row

สำหรับการเชื่อมต่อกับ MariaDB Galera Cluster นั้นสามารถใช้ MySQL Library โดยทั่วไป โดยไม่ต้องแก้ไข code ใดๆ (นอกจากแก้ไขตามข้อจำกัดของระบบ Cluster บางอย่าง)

แน่นอนว่ามีข้อดีก็ต้องมีข้อจำกัด โดยข้อจำกัดของ MariaDB Galera Cluster นั้นคือ

  • ใช้ได้แต่ InnoDB storage engine เท่านั้น ถ้ามี MyISAM storage engine ให้ alter เสียก่อน
  • การที่ MariaDB Galera Cluster สามารถเพิ่มข้อมูลที่ตัว node ใดๆ ก็ได้ ต้องปรับแก้ auto_increment_increment และ auto_increment_offset ให้สอดคล้องกับ cluster node ที่ใช้ auto increment ใน table ต่างๆ แนะนำให้ใช้การเพิ่มข้อมูล 1-2 cluster node เพื่อป้องกันการทำ auto increment ซ้ำซ้อนกัน
  • สำหรับการใช้ DELETE ต้องใช้กับ table ที่มี primary key คำแนะนำง่ายๆ ถ้าจะใช้ table ทุกๆ ตัวต้องมี primary key และการ DELETE ต้องทำผ่าน primary key
  • เมื่อเป็น multi-master replication การใช้ binlog-do-db และ binlog-ignore-db จึงทำไม่ได้ รวมไปถึงใช้ Query cache ไม่ได้ (แนะนำให้ใช้ Memcached แก้ไขปัญหาแทนได้)
  • ทำ LOCK/UNLOCK TABLES และใช้ XA transactions ไม่ได้ (แต่ยังใช้ Transaction ตามปรกติได้)
  • แนะนำให้ใช้เพียง character_set_server แบบ utf8 เท่านั้น
  • ไม่สนับสนุนบน Windows

สำหรับในการติดตั้งนั้นไม่ได้ยุ่งยากอะไรนัก ใช้ตัว configuration ของ wsrep ในการตั้งค่าต่างๆ (MySQL Write Set Replication; MySQL-wsrep) โดยเข้าไปแก้ไขใน my.cnf สามารถทำตาม ที่บทความ Install MariaDB Galera Cluster in Ubuntu ได้เลย

เมื่อแอพบน Windows 8.1 และ Windows Phone 8.1 กำลังรวมกันด้วย Universal WinRT อาจตัดสินอนาคตของ Microsoft

อนาคตของ Windows ในตลาด tablet และ mobile นั้นดูจะยังลุ่มๆ ดอนๆ อยู่พอสมควร อาจจะเพราะชะล่าใจ จนเข้ามาช้าไป อีกทั้งเข้ามาช้าก็เร่งเครื่องไม่ทันกระแส พัฒนาไล่ตามคู่แข่งแบบหวานเย็น จนเหล่านักพัฒนา และผู้ใช้ที่ติดตามฝั่ง Windows ได้แต่มอง platform อื่นๆ เค้าก้าวหน้าไปอย่างรวดเร็ว

แม้ว่าช่วงปีที่ผ่านมา จะเห็นได้ว่า Microsoft ได้วางแผนว่า Windows ในอนาคตจะต้องให้ประสบการณ์ในการใช้งานตั้งแต่หน้าจอประมาณ 3” จนถึง 30” แล้วมีประสบการณ์เดียวกัน ซึ่ง codename ชื่อ Windows Blue เป็นแผนงานที่วางไว้ในช่วงปีที่แล้วจนถึงปีนี้ แต่ดูเหมือนแผนงานฝั่ง Windows desktop และ tablet ก็ดูจะได้รับการตอบรับที่ดีในระดับหนึ่ง ซึ่งถูกมองว่าเป็นแผนงานอุดข้อเสียและปรับปรุงให้ดีขึ้นมากกว่า ส่วนในด้านของ Windows Phone ก็ช้ากว่าฝั่ง Windows เข้าไปอีก ด้วยการออก Windows Phone 8 GDR 1, GDR 2 และ GDR 3 ที่ดูเหมือนจะเป็นเพียงการไล่ตามในสิ่งที่ผู้เล่นในตลาดมีอยู่ก่อนแล้วมาก่อน 1-2 ปี

แต่จากข่าวในช่วงเดือนที่ผ่านมาของ Windows Phone 8.1 (codename: Blue) นั้น ได้สร้างความตื่นเต้นพอสมควรในด้านความสามารถที่มากมายกว่า Windows Phone 8 GDR 1 จนถึง GDR 3 รวมกันเสียอีก อีกทั้ง ส่วนที่น่าสนใจมากกว่านั้นคือ ได้มีข้อมูลที่รวมการพัฒนาแอพบน Windows 8.1 และ Windows Phone 8.1 เข้าด้วยกัน สร้างความน่าสนใจมากกว่าข่าวลือเรื่อง Microsoft มีความคิดจะนำแอพ Android มาทำงานบน Windows เสียอีก

จากเอกสาร Windows Phone 8.1 SDK ที่หลุดออกมานั้น เปิดเผยว่า Windows Phone 8.1 ช่วยให้นักพัฒนาสามารถสร้างแอพโดยใช้ Universal Windows Runtime (หรือเรียกอีกชื่อว่า Universal WinRT) ได้ โดยเป็นผลดีต่อต้นทุนในการพัฒนาแอพเป็นอย่างมาก ซึ่งชื่อ “WinRT” นั้น คงคุ้นหูกันมาก่อน เพราะมันคือชื่อ runtime ของแอพ Windows Store apps บน Windows RT และ Windows 8 อยู่ก่อนแล้ว นั้นหมายความว่า เราสามารถสร้างแอพที่ทำงานได้ทั้งบน Windows Phone 8.1 และ Windows 8.1 ได้ในการพัฒนาเพียงครั้งเดียว ในชื่อ “Universal Store apps” เพื่อใช้เรียกว่า runtime ใหม่ ให้แยกต่างหากจากของเดิมที่ชื่อ “WinRT”  เป็น “Universal WinRT” แน่นอนว่าสำหรับแอพเดิมที่เคยพัฒนาอยู่ก่อนแล้วบน Windows Phone 8 นั้นสามารถอัพเกรดแอพด้วยการคอมไพล์ไปใช้ Windows Phone Silverlight 8.1 (หรือเรียกอีกชื่อว่า WP Silverlight 8.1) แทนได้เช่นเดิม หรือจะพัฒนาโดยใช้ Universal WinRT ก็ได้โดยเริ่มต้นสร้าง Solution ใน Visual Studio ใหม่อีก Solution หนึ่งจาก Template ที่มีอยู่ใหม่

แต่ทั้งนี้ ด้วยข้อจำกัดของทั้ง Universal WinRT และ WP Silverlight 8.1 นั้นมีหลายส่วนในเบื้องต้น ซึ่งข้อจำกัดใน Universal WinRT นั้นยังมีอยู่มากตามเอกสารที่หลุดออกมา และคิดว่าน่าจะเข้าใกล้การพัฒนาจนไร้ข้อจำกัดในการผสานกันระหว่าง Windows 8และ Windows Phone ในอนาคต

ส่วนต่อมาที่น่าสนใจในเอกสารคือ Share โดยถ้าว่ากันตามจริง ใช้หลักการเดียวกับบน Windows 8 ที่ใช้การส่ง command ไปยังแอพปลายทาง (target app) และเมื่อแชร์จบแล้วจึงย้อนกลับมาที่แอพเดิม (source app) ทำให้ต่อการ การแชร์ระหว่างแอพจะทำได้สะดวกขึ้น และไล่ตามความสามารถของคู่แข่งได้สูสีมากขึ้น

สำหรับข้อมูลส่วนอื่นๆ ที่น่าสนใจตามเอกสาร SDK ที่หลุดมา จะเป็นส่วนของการเตรียมตัวและพัฒนาแอพให้สามารถทำงานบน Windows Phone 8.1 ได้อย่างราบรื่นและสมบูรณ์ รวมไปถึงทำความเข้าใจแนวคิดใหม่ของ Universal WinRT ที่กำลังจะเป็นส่วนสำคัญในการพัฒนาแอพในอนาคตด้วย

จากการวิเคราะห์นั้น คิดว่าการพัฒนาแอพที่สามารถทำงานได้กับอุปกรณ์ทั้ง desktop, tablet และ phone ในตัวเดียว อาจจะสร้างความยุ่งยากอยู่พอสมควร ในการแสดงผลให้แตกต่างกันในแต่ละอุปกรณ์ แต่ถ้ามองในมุมบริหารจัดการ และการจูงใจนักพัฒนาแอพบน desktop และ tablet มาพัฒนาบน phone และในทางกลับกัน นักพัฒนาบน phone ก็ขยับมาลงใน desktop และ tablet นั้นดูน่าสนใจมากขึ้น เพราะในขณะนี้ รูปแบบการพัฒนานั้นดูจะแตกต่างกันอย่างเห็นได้ชัด และการพัฒนาแอพบน Windows Store apps นั้นก็ง่ายกว่าบน Windows Phone apps อย่างมาก ซึ่งจุดนี้เองที่น่าสนใจว่าผู้เล่นจากฝั่งไหนจะลงมาเล่นมากกว่ากัน ต้องลองติดตามต่อไป ถ้าเอกสารที่หลุดมานั้นเป็นเอกสารจริง

หมายเหตุ เอกสารต่างๆ ที่หลุดออกมานี้ แนะนำให้ลองหาดูกัน ผมคงไม่สามารถโพสเอกสาร หรือแจกจ่ายเอกสารเหล่านี้ได้ด้วยข้อจำกัดทางกฎหมายในตัวเอกสารเอง (ถ้าเป็นเอกสารของ Microsoft จริง)

ประสบการณ์ในการเปลี่ยนแบตเตอรี่ของ Nokia Lumia 920 จาก ศ. Nokia Care

ผมใช้ Nokia Lumia 920 มาประมาณ 1 ปีกับอีก 2 เดือนนิดๆ ถามว่าใช้แล้วมีความสุขไหม ก็ต้องบอกว่าโอเคในระดับที่ประทับใจ แน่นอนหลายคนที่รู้จักผมจะทราบว่าผมมันติ่ง Microsoft พอสมควร แต่แน่นอนห่วยก็ด่า ดีก็ชม มันก็ง่ายๆ ผมใช้ Lumia 920 และ Windows Phone 8 มาตั้งแต่เริ่มเปิดตัวใหม่ๆ ในไทย ช่วงเดือน พ.ย. 2012 จนวันนี้ 13 ก.พ. 2014 ถ้าพูดในเรื่องเสถียรภาพ ต้องบอกว่าไม่ค่อยผิดหวังเท่าไหร่ ในด้านการใช้งานทั่วไป ไม่เคยเจอว่าอยู่ๆ ดับไปเองสักครั้ง หรือรีเซตตัวเองในเวลาที่จำเป็นต้องใช้รีบๆ ส่วนเรื่องแอพก็ค่อยๆ มา แรกๆ ที่ใช้ก็หงุดหงิดเรื่องนี้ เพราะย้ายมาจาก Android แต่พอเริ่มทำใจ เริ่มปรับตัว ประกอบกับหลังๆ ดีขึ้นเป็นลำดับ

แต่ในช่วง 1-2 เดือนให้หลังมานี้อายุการอยู่ของแบตเตอรี่ของเครื่องค่อนข้างแย่ลง เลยหาข้อมูลการเปลี่ยนแบตเตอรี่ ซึ่งไม่ค่อยมีประสบการณ์ในการเปลี่ยนให้เน็ตให้ได้อ่าน หรือมีข้อมูลราคาของ ศ. Nokia Care เลย

ผมเลยตัดสินใจโทรเข้า Nokia Careline เพื่อสอบถามเรื่องราคาแบตเตอรี่ แต่ผมก็ได้ความน่าหงุดหงิดของ Nokia Careline กลับมาพอสมควร คือสอบถามเรื่อง ราคาแบตเตอรี่ ค่าดำเนินการเปลี่ยน และระยะเวลาในการเปลี่ยน แต่เจ้าหน้าที่ Nokia Careline กลับตอบคำถามลูกค้าไม่มีเซ้นสักท่าไหร่เลย คือ ตอบแบบโยนๆ ให้ไปสอบถาม ศ. Nokia Care เอง และไม่ได้ประสานงานช่วยลูกค้าอะไรมากไปกว่าบอกว่า ทาง Nokia Careline ไม่มีข้อมูลราคาในส่วนนี้ และให้โทรไปที่ ศ. Nokia Care ที่ใกล้ที่สุดมาแทน

พอได้ข้อมูลที่ไม่ค่อยได้ช่วยอะไรมากนัก ผมก็เลยโทรไปที่ ศ. Nokia Care ที่เราใกล้สุดตามที่ Nokia Careline แจ้ง คือ ศ. Nokia Care สาขา MBK แต่ไม่มีใครรับสาย ด้วยความสิ้นหวัง ก็เลยเข้า Live Chat ของ Nokia Care ผ่านเว็บ แล้วก็ได้คำตอบเดียวกับ Nokia Careline ในข้างต้น แต่รอบนี้ ได้เบอร์ ศ. Nokia Care สาขาอื่นๆ มาเพิ่มแล้วให้เราโทรไปสอบถาม ศ. Nokia Care อื่นๆ ที่ได้มาอีกรอบ แต่ท้ายที่สุด เจ้าหน้าที่ Live Chat ของ Nokia Care ก็แนะนำให้เข้าไปสอบถามที่ ศ. ที่ใกล้ที่สุด จะได้คำตอบที่ตรงที่สุด

โอเค … คือถ้าผมว่างมีเวลาเข้าไปที่ ศ. Nokia Care สาขา MBK ผมคงไม่โทรหา Nokia Careline หรือ Live Chat หรอก

อ่ะ ข้อเสนอให้ปรับปรุงในส่วนนี้คือ บริการ Nokia Careline และ Live Chat ควรจะมีข้อมูลในส่วนนี้ แม้จะมีคนสอบถามปีละ 2-3 หรือหลายสิบคน ก็ควรจะเป็นเรื่องที่ควรประเมิณได้ทางโทรศัพท์ เพราะไม่ได้เกี่ยวกับตัวเครื่องที่นำไปให้ช่างซ่อมที่ ศ. Nokia Care ตรวจสอบ ควรทำเหมือน check list แล้วเสนอราคาได้เลยว่าประมาณเท่าไหร่ คือไม่ต้องตรง 100% แต่พอจะเข้าใจ หรือเตรียมตัวได้เวลาเข้าไปที่ ศ. Nokia Care

โอเค จบเรื่องบ่นๆ ยาวๆ ด้านบน มาต่อว่าผมเปลี่ยนแบตเตอรี่มามีขั้นตอนอย่างไรบ้าง

การเปลี่ยนแบตเตอรี่ของ Nokia Lumia 920 สำหรับเครื่องหมดประกันแล้วนั้น ทาง ศ. Nokia Care มีค่าใช้จ่ายให้เราชำระอยู่ 2 ส่วน คือ ค่าแบตเตอรี่และค่าดำเนินการซ่อม รวม 1,670 บาท (รวม VAT 7% แล้ว) โดยเป็นค่าดำเนินการซ่อมในใบรับเครื่องระบุไว้ 400 บาท ส่วนที่เหลือคือค่าแบตเตอรี่

โดยแบตเตอรี่ที่เปลี่ยนใหม่จะมีประกันตัวแบตเตอร์รี่ 1 ปีหลังจากเปลี่ยนแบตเตอรี่ไปแล้ว โดยทาง ศ. Nokia Care จะออกใบเสร็จให้เราเก็บไว้ และคืนแบตเตอรี่เก่าให้เราด้วย

ขั้นตอนการเข้าไปใช้บริการไม่มีอะไรมาก เข้าไปหยิบบัตรคิวแล้วบอกเจ้าหน้าที่ เจ้าหน้าที่จะตรวจสอบเครื่อง และเช็คประกันให้ (ของผมมันหมดประกันแล้ว ไม่ต้องเช็ค) แล้วเจ้าหน้าที่จะตรวจอะไหล่ว่ามีหรือเปล่า แต่พอดีว่าวันก่อนหน้าเข้าไป 1 วันไปสอบถามถึง ศ. Nokia Care มารอบแล้ว เพราะเหตุการณ์ข้างต้นนั้นแหละ แต่ไปตอน ศ. Nokia Care จะปิดแล้ว เลยเปลี่ยนไม่ทัน เลยทราบข้อมูลว่าอะไหล่แบตเตอรี่มีของ วันต่อมาเลยเข้าไป ซึ่งเมื่อมีอะไหล่ก็ทำเรื่องเปลี่ยน ระยะเวลาในการเปลี่ยนประมาณ 2 ชั่วโมง ไม่ต้องรอข้ามวัน แต่ยังไงผมก็แนะนำว่าให้ไปช่วงเช้าหรือเที่ยงๆ อย่าไปช่วงเย็น เพราะอาจจะต้องทิ้งเครื่องค้างคืน

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

ทั้งหมดก็หวังว่าจะเป็นข้อมูลสำหรับคนที่จะเข้าไปเปลี่ยนแบตเตอรี่ ของ Nokia Lumia รุ่นที่เปลี่ยนแบตเตอรี่เอง โดยผู้ใช้งานไม่ได้ครับ ;)

2Uc2Nu

แอพ Android บน Windows platform เป็นไปได้แค่ไหน?

เป็นงานเขียนที่เป็นแนวคิดแบบเร็วๆ ที่ในตอนแรกว่าจะเขียนสั้นๆ บน facebook แต่คิดว่าน่าจะต่อยอดวิธีคิด และสร้างวิธีคิดที่ละเอียดได้มากขึ้น เลยเขียนลงที่นี่น่าจะดีกว่า โดยมาจาก “ข่าวลือ” ที่ว่า Microsoft มีแผนให้แอพบน Android รันบน Windows และ Windows Phone ได้

ในความเห็นส่วนตัวมองว่า ในระยะยาว Microsoft จะไม่ได้อะไรจากการที่สามารถทำให้แอพบน Android นั้นรันบน Windows platform ได้ (ผมใช้คำว่า platform เพราะต้องการพูดรวมๆ ทั้ง Windows และ Windows Phone) เนื่องจากการทำแบบนั้น ย่อมเท่ากับทำลาย ecosystem ของตัวเองที่กำลังสร้างขึ้นในระยะเวลา 2-3 ปีที่ผ่านมา ซ้ำร้ายอาจจะทำลาย ecosystem ทั้งหมดที่ตัวเองมีมาอย่างยาวนานอีกด้วย

ทำไมถึงเป็นเช่นนั้น …. ต้องย้อนกลับไปดูว่า ecosystem ที่ตัวเองกำลังสร้างขึ้นในช่วงที่ผ่านมา และยังเป็นอนาคตของ Microsoft อย่าง Windows Store apps และ Windows Phone apps นั้น การทำตามที่ข่าวลือออกมา อาจเป็นการทำลายความน่าสนใจใน ecosystem ลงโดยสิ้นเชิง ซึ่งเป็นเรืองที่ร้ายแรงมาก เพราะถึงแม้ ในระยะสั้น กองทัพแอพของ Android ที่มาลงใน platform จะมหาศาลมาก สร้างความน่าสนใจต่อการดึงดูดผู้ใช้ และนักพัฒนาให้หันกลับมาใช้ Windows platform เพื่อใช้ และพัฒนาแอพ Android ได้ในระยะสั้นๆ แต่ในระดับ ecosystem ที่ตัวเองถืออยู่ก่อนแล้วจะไม่โต สุดท้ายจะไม่รอดทั้งหมด เพราะหมายถึงไปลดความสำคัญของ ecosystem ที่มีอยู่ และอาจรุกไปถึง การที่นักพัฒนาถอยห่างออกจาก .NET Framework ไปใช้ชุดพัฒนาอื่นๆ ที่เหมาะสมกับการพัฒนาบน Android แทน เพราะดันไปลดความได้เปรียบในการควบคุม platform ที่มีอยู่ในอดีตตให้กับ Google

แน่นอนว่าการไม่เอา Android ก็อาจจะทำให้การต่อสู้ระยะยาวมีปัญหา ในความคิดเห็นส่วนตัวมองว่าควรใช้ Mobile division ที่กำลังจะปิดดีลกับทาง Nokia มาเป็นประโยชน์ อาจจะสร้าง ecosystem กันชน (คล้ายๆ กับ Amazon) เพื่อเหยียบเรือสองแคมไปก่อนเพื่อสร้างความคุ้นเคยในตลาดที่ Microsoft ไม่ถนัด (ผมมองว่าไม่ถนัดอย่างมาก จากการเห็นลักษณะง่อยๆ ของ Windows Phone 8 ในช่วง 1 ปีกว่าๆ) โดยนำเอาประสบการณ์ของ Nokia ที่มีประสบการณ์ในการพัฒนาโทรศัพท์ มาปรับปรุง ecosystem บน platform ของตนเอง ซึ่งจะเป็นเรื่องที่น่าจะดีกว่าในการทำกำไร และสร้างความคุ้นเคย พัฒนาซอฟต์แวร์อื่นๆ ให้ทำงานบน Android ให้ได้ดีมากขึ้น รวมไปถึงการเก็บค่าพัฒนา หรือเช่าใช้ตามแนวทางใหม่ของตัวเองด้วย

สำหรับตัวอย่างที่เห็นได้ชัดเจนที่สุดที่นำเอาแอพ Android มาทำงานบน platform ตัวเองแล้วไม่ประสบความสำเร็จอย่างสิ้นเชิง คือ BlackBerry ซึ่งในตัว BB 10 นั้น BlackBerry ได้ประกาศว่าสามารถที่จะพอตตัวแอพของ Android มาลงได้ไม่ยากนัก เพื่อหวังจะเพิ่มจำนวนแอพให้พุ่งขึ้นอย่างรวดเร็ว และวิ่งไล่ทัน Android ในระยะเวลาอันสั้น โดยหวังว่าจะใช้ความได้เปรียบตรงนี้ในการจูงใจผู้ใช้ และนักพัฒนา ให้หันกลับมาพัฒนาแอพในระดับ native ในที่สุด ซึ่งในตอนแรกที่เปิดตัวก็ดูว้าวดี แต่สุดท้ายนักพัฒนาก็เอาง่ายเข้าว่าด้วยการพอตตัวแอพจาก Android มาทั้งหมดโดยไม่ได้ปรับปรุงให้เข้ากับประสบการณ์การใช้งานของ BB 10 ที่แตกต่างกันในหลายๆ ส่วน และในบางแอพยังมีประสิทธิภาพที่แย่ (ถึงแย่มาก) อีกทั้งตัว runtime ของ BB 10 ที่ใช้สำหรับให้แอพ Android ทำงานนั้น ก็กินทรัพยากรมากกว่า ซึ่งเป็นผลร้ายต่อประสบการณ์ในการใช้งานระยะยาวของกลุ่มผู้ใช้ที่แย่จนรับไม่ได้ในที่สุด

ถ้า Microsoft จะดำเนินตามแผนที่ BlackBerry เคยทำ อาจจะจบไม่สวยก็เป็นได้ …