Blog

 

อุปกรณ์ที่ชาร์จด้วย USB เริ่มเยอะ เลยแนะนำ Orico Wall AC USB Charger ขนาด 30W ทั้งแบบ 4-Port และ 5-Port

by

มาในช่วงพักหลังๆ อุปกรณ์ต่างๆ เยอะขึ้น การพกที่ชาร์จ 3-4 อันเวลาไปเที่ยวมันดูเยอะไป พกยาก เลยคิดว่าควรหาที่ชาร์จแบบมีหลายๆ ช่องสำหรับชาร์จได้ พอทีเดียวแล้วครอบคลุม วันเสาร์ที่ผ่านมา มีจังหว่ะไปเดิน Commart 2014 แล้วก็เดินๆ เล่นๆ ก็ไม่ได้คิดว่าจะมีสักเท่าไหร่ เพราะส่วนใหญ่ขายแบบ 2 port ก็เยอะแล้ว แต่ไปสะดุดที่บูท Orico ท้ายๆ ง่าย ซึ่งมีช่องสำหรับให้ต่อสายชาร์จได้ค่อนข้างเยอะ ระดับ 4-5 ช่อง แถมสามารถต่อสายชาร์จเพื่อชาร์จ iPad ได้สองช่องพร้อมกันได้อีก เลยสนใจถอยมา 2 แบบ ใช้ส่วนตัวแบบ 5 ช่องและ 4 ช่อง อันนี้ให้คุณแฟนใช้

Orico 5-Port Wall AC USB Charger (30W)
x2 (port 1-2) 5VDC @ 2A (iPad)
x3 (port 3-5) 5VDC @ 1A

ตัวนี้ชาร์จ iPad ได้ 2 ตัวพร้อมกัน แต่ต้องใช้ port 1-2 โดยที่ port 3-4 ชาร์จ iPhone ได้ ส่วน port 5 ปล่อยว่างไว้ แต่ถ้าอยากใช้พร้อมทั้ง 5 port ต้องชาร์จ iPad, iPad mini (Tablet 7″) และมือถืออีก 3 เครื่อง ถึงจะใช้พร้อมกัน

DSC_7504

DSC_7509_1

Orico 4-Port Wall AC USB Charger (30W)
x2 (port 1-2) 5VDC @ 2A (iPad)
x2 (port 3-4) 5VDC @ 1A

ตัวนี้ชาร์จ iPad ได้ 2 ตัวพร้อมๆ กับชาร์จ iPhone ได้ด้วย ไม่ยุ่งยากเท่า 5 port

DSC_7505

DSC_7518

สำหรับราคา Orico Wall AC USB Charger แบบ 5 port จะมีราคาอยู่ที่ 990 บาท ส่วนแบบ 4 port มีราคาอยู่ที่ 890 บาท

สำหรับ Shop ของ Orico อยู่ที่ IT Mall Fortune ดูรายชื่อร้านขายได้ที่นี่

 

เราเสียประโยชน์กันไปแค่ไหนแล้ว กับการส่งซ่อมสินค้านานนับเดือน

by

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

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

การซ่อมเร็วผมไม่เรียกว่าเป็นเรื่อง “ดี” ถ้าไม่มีการขยายระยะเวลารับประกันออกไปแต่ผมเรียกว่า “เสียประโยชน์น้อยที่สุด” มากกว่า

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

เราคงได้ฉุกคิดว่า การส่งสินค้าเข้า ศ. บริการ เพื่อซ่อมแซมนั้น เราเสียประโยชน์อย่างไร และแบรนด์ควรรับผิดชอบเพิ่มเติมอย่างไร

 

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

by

จากกระทู้ต้นเรื่อง 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 ในเบื้องต้น

by

เป็น 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

by

อนาคตของ 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 จริง)