Month: May 2013

3G 2100 ทั้ง 3 ค่าย กำลังทำผิดอยู่หรือไม่?

by

จากข้อมูล มาตรฐานการให้บริการข้อมูล 2G/3G ของ กสทช.

  • RTT (round trip time)
    • 2G: 1,000 ms
    • 3G: 500 ms
  • FTP success ratio
    • download: 80% (2G/3G)
    • upload: 70% (2G/3G)
  • FTP mean data rate
    • 2G download: 48 kbps
    • 3G download: 345 kbps
    • 2G upload: 20 kbps
    • 3G upload: 153 kbps
  • HTTP success ratio
    • 2G: 80%
    • 3G: 90%

และเพื่อไม่ให้ข้อมูลผิดพลาด เลยไปดูที่เว็บ กสทช. แล้วดูเอกสารที่ลิงค์ “ประกาศ กสทช. เรื่อง มาตรฐานของคุณภาพการให้บริการโทรคมนาคมประเภทข้อมูลสำหรับโครงข่ายโทรศัพท์เคลื่อนที่” http://www.ratchakitcha.soc.go.th/DATA/PDF/2555/E/152/20.PDF

หน้าตาประมาณนี้

2013-05-09_231802

ไล่หาลงมาเรื่อยๆ ผมไม่ได้พูดยกมาเอง ที่หน้า 7-8

 2013-05-09_232013จะเห็นในส่วนของ ความเร็วเฉลี่ยในการส่งข้อมูลของ FTP “กรณี Download สำหรับ 3G ขึ้นไป ไม่ต่ำกว่า 345 Kbps” หรือตีความตามความเข้าใจคือ “อัตราความเร็วในการรับ-ส่งข้อมูลต้องไม่น้อยกว่าอัตราที่กำหนดไว้ คือ 345kbps”

แต่….

  • “Choice Package” ของ dtac ทุกโปรตั้งแต่ 429 – 949 บาทนั้น หลังใช้งานครบจำนวนข้อมูลที่กำหนดจะปรับลดความเร็วไม่เกิน 64 Kbps
    อ้างอิง http://www.dtac.co.th/postpaid/trinetpackage
  • “3G iSmart Package” ของ AIS ราคาเริ่มต้นที่  299 – 999 บาทนั้น หลังใช้งานครบจำนวนข้อมูลที่กำหนดจะปรับลดความเร็วไม่เกิน 64 Kbps – 256 Kbps
    อ้างอิง http://www.ais.co.th/3g/3g_package/
    “iSmart Package” ของ Truemove H ราคาเริ่มต้นที่ 299 บาทนั้น หลังใช้งานครบจำนวนข้อมูลที่กำหนดจะปรับลดความเร็วไม่เกิน 128 Kbps
    อ้างอิง http://truemoveh.truecorp.co.th/3g/packages/ismart/entry/594

คำถามว่าทั้ง 3 ค่าย ทำผิดอยู่หรือไม่?

ผมสับสนว่า “เมื่อใช้งานครบจำนวนข้อมูลที่กำหนด” ทั้ง 3 ค่ายสามารถปรับลดความเร็วได้ต่ำลงได้ขนาดนั้นเลยหรือ? เพราะเหมือนไม่มีใครสนใจ คงต้องให้ผู้รู้มาตีความต่อไปว่าผิดหรือไม่ผิดต่อไป

การดูหนังในโรงต้องคิดเยอะขึ้น

by

หลังจากเรื่องตั๋วหนังแพง ของกินหน้าโรงแพง แถมโฆษณาในโรงก่อนฉายเยอะ ผมเลยมีมาตรการส่วนตัวที่จะดูในโรงอยู่บางส่วนที่อาจจะทำร้ายจิตใจใครหลายๆ คน จริงๆ เคยเขียนไว้ใน เหตุง่ายๆ ที่คงไม่ได้ดู “ภาพยนตร์คอนเสิร์ต Bodyslam นั่งเล่น” แล้วแต่ว่ารอบนี้เอามาสรุปใหม่อีกสักรอบดีกว่า

  1. จะดูโรง Major เพราะ IMAX เท่านั้น เพราะโฆษณาน้อย ไม่รอนาน คุณภาพที่ยอมจ่าย ช่องขายตั๋วที่น้อยและหวังขายบัตรเติมเงิน (ขายตั๋วแพงแต่ไม่มีปํญญาเพิ่มช่องขาย)
  2. เรื่องที่อยากดูมากๆ แต่เน้น Digital จะไปดู SF หรือเครือ APEX ทั้งหมด ส่วนฟิล์มก็ไปดู APEX เท่านั้น
  3. หนังไทยจะไม่ดูในโรงหนังอีกต่อไป เริ่มตั้งแต่ พี่มาก คู่กรรม และหลายๆ เรื่อง ต้องขอโทษที่มันโหดร้าย แต่ถ้าตั๋วหนังราคายังแพงเท่ากับหนังฟอร์มใหญ่ แล้วโรงหนังบางโรงยังหน้าด้านบอกว่าหนังต้นทุนสูงเลยต้องขึ้นราคา แต่หนังไทยหลายๆ เรื่องราคาตั๋วเท่ากับฟอร์มใหญ่แบบนี้ มันดูแปลกๆ เพราะงั้น ผมซื้อแผ่นดูดีกว่า (พี่มากและคู่กรรมผมยังไม่ได้ดูเลย รอแผ่นครับ)
  4. ขนมหน้าโรงจะไม่ซื้อเลยนอกจากเครือ APEX เท่านั้น (SF/Major ราคาโหดร้ายทั้งคู่ แต่ Major ราคาโหดมากกว่า และ APEX ราคาประมาณแถวๆ ศ. ท่ารถหมอชิต ซึ่งผมรับได้)
  5. โฆษณาเยอะ เป็นเหตุผลสำคัญที่ไม่เลือกดู Major และย้ายมาดู SF แทน และที่นั่ง SF นั่งสบายกว่า Major เยอะด้วย
  6. ราคาแพงทำให้ผมเลือกที่จะดูหนังเยอะขึ้น เรื่องไหน 50-50 ผมไม่ดูในโรงเลย คือไม่เสี่ยงกับราคาตั๋วโหดร้ายพวกนั้นเด็ดขาด

ผมคงไม่ทำให้เค้าขาดทุนหรอก แต่ถือว่าเป็นเสียงเล็กๆ ที่สะท้อนแล้วกัน

Software เป็นแบบ Subscription (เช่าใช้งาน) ทางออกของการขาย Software ในปัจจุบันและอนาคต

by

Office 365 และ Office 2013 วางขายผ่านเว็บไมโครซอฟท์ประเทศไทยแล้ว หรือล่าสุดอย่าง Adobe ยกเลิก Creative Suite ต่อไปนี้จะกลายเป็น Creative Cloud ส่วนตัวผมก็รอ Creative Cloud แบบ End User อยู่ เอาแบบไม่ต้องกรอกหลอกระบบว่าอยู่สิงค์โปร์เนี่ยแหละครับ

ส่วนตัวแล้วจ่ายได้นะเดือนละ 100-1,500 บาทโดยประมาณกับการได้ software ครบชุดแบบนี้ จ่ายสบายๆ เดือนแค่นี้ กับการรับงานแล้วได้เงินมากกว่านี้หลายเท่าตัว (ก่อนหน้านี้จ่าย Office 365 Small Business Premium ไปแล้วเดือนละประมาณ 400-450 บาท)

การที่ Software เป็นแบบ Subscription (เช่าใช้งาน) เป็นการมองว่าต่อไป Software จะเป็นเหมือนองค์ประกอบหนึ่งของการทำธุรกิจที่ไม่ต่างจาก น้ำ, ไฟฟ้า หรืออาคารสำนักงานให้เช่าใจกลางเมือง อะไรแบบนั้น

แนวโน้มของ Software จะไปในแนวทาง Subscription (เช่าใช้งาน) มากขึ้นเรื่อยๆ เพื่อลดปัญหาการละเมิดลิขสิทธิ์ การ update/upgrade ที่ทำให้ Software ทำงานได้สมบูรณ์ที่สุด ตัดช่องทางการขายผ่าน Dealer ที่ช้าและมัก Support ไม่ดี ใช้การ Support แบบ online แทน ทำให้บริษัทพัฒนาซอฟต์แวร์เห็นถึงความต้องการของผู้ใช่งานได้มากขึ้นด้วย (เจอมาเยอะ เบื่อมาก กว่าจะได้คำตอบ ทวงแล้วทวงอีก)

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

บันทึกสั้นๆ หลังใช้งาน Windows Azure Storage Table

by

ตอนนี้ใช้ Windows Azure Storage Table อยู่กับบางบางตัว ซึ่งหลังจากที่ใช้งานมา 3-4 วันที่ผ่านมา เอาสิ่งที่ได้มาแบ่งบันกันเล็กน้อย

  • มันเป็น NoSQL database เรื่อง schema โยนทิ้งไปเลย คิดใหม่ทำใหม่หมด คล้ายๆ Excel มากกว่าด้วยซ้ำ
  • มี Data type ไม่เยอะ ทำงานง่ายพอสมควร
  • รองรับข้อมูลที่ใส่ลงไปไม่เกิน 100 TB ต่อฐานข้อมูล
  • สื่อสารกันผ่าน HTTP / HTTPS มี SDK API ให้หลายๆ ภาษาทั้ง .NET Framework, Java, PHP, Node.js, Python ฯลฯ หรือจะติดต่อผ่าน CURL อะไรพวกนี้ก็ได้ แล้วแต่ความถึกแต่ละคน (แต่ผ่าน SDK มันจะง่ายกว่าเยอะมาก)
  • ใน 1 Table สามารถกำหนด entity (row/record ใน RDBMS) ให้มี properties (field/column ใน RDBMS) หลากหลายได้ ไม่จำเป็นต้องเป็น entity ที่มี properties เหมือนๆ กัน
  • entity แต่ละตัวที่ใส่ลงไปได้มีข้อมูลไม่มากเกินกว่า 1MB ต่อ entity
  • properties ตั้งได้ไม่เกิน 252 ตัวต่อ 1 entity
  • properties ที่จำเป็นต้องส่งเข้าไปหรือใช้งานมี 3 ตัวคือ partition key, row key และ timestamp ซึ่ง partition key, row key เราต้องกำหนดเอง ส่วน timestamp ไม่ส่งเข้าไปก็ได้ระบบจะใช้เวลาของระบบแทน
  • ค่า partition key และ row key จำเป็นอย่างมากในการ update/delete ต้องออกแบบดีๆ ค่า partition key เปรียบเสมือนกลุ่มข้อมูล (คล้าย Class) ซ้ำได้ ส่วน row key จำซ้่ำไม่ได้ในแต่ละ partition key เปรียบเสมือน primary key ใน RDBMS ต้องใส่ข้อมูลทั้งสองลงไปเสมอ
  • การส่งข้อมูลออกมาจากการ Query นั้นจะส่งมาไม่เกิน 1,000 entities เท่านั้น ถ้าต้องการมากกว่านั้นต้อง request อีกรอบด้วยการใช้ NextPartitionKey และ NextRowKey ร่วมด้วยในการ Query ครั้งต่อไปจึงจะได้ข้อมูลช่วงถัดมาอีก 1,000 entities
  • ไม่สามารถ Sorting หรือแบ่ง Pagination ได้ ถ้าอยากทำต้อง query มาทั้งหมดแล้ว Sorting ในระบบเอาเอง หรือใช้ร่วมกับ RDBMS ตัวอื่นๆ แทน แล้วเก็บเฉพาะ partition key และ row key เพื่ออ้างอิงพ่วงกับข้อมูลที่ต้องการ Sorting จะช่วยได้มาก
  • สามารถค้นหาจาก properties ที่ไม่ใช่ partition key, row key และ timestamp ได้ จะ full table query ก็ทำได้ จากที่ลอง 1 แสน entity ก็ทำงานได้ดี (ข้อมูลประมาณ 50MB) ค้นหาด้วย properties ที่ไม่ใช่ตัวหลักของระบบ และเป็น full table query ไม่เกิน execute time
  • การ import ข้อมูลทำได้หลายแบบ ที่สะดวกที่สุดคือ csv ที่ export จาก Excel หรือฐานข้อมูลตัวอื่นๆ แค่กำหนด first line ให้เป็นชื่อ properties ที่กำลังใส่ลงไปมันจะไป map ตัว properties ในตารางให้เอง แต่  Data type มันจะเป็น String
  • ระยะเวลาในการ execute time มากสุดที่ 5 วินาที
  • ระยะเวลาในการให้ client request ไม่เกิน 30 วินาที

อันนี้คือเท่าที่ลองๆ ใช้มา

Jarvis ใน IRONMAN ใช้ระบบอะไรในการประมวลผลและเก็บข้อมูล

by

Stark Industries ใช้ Oracle Cloud ในการจัดการระบบทั่วโลกรวมไปถึง Jarvis และ Services ที่ใช้ก็ได้แก่
– Oracle Social Network Cloud Service
– Oracle Database Cloud Service instance
– Oracle Java Cloud Service
– Oracle Exadata database appliance
– Oracle Exalogic Elastic Cloud
อ้างอิง: http://www.oracle.com/us/ironman3/omag-mj13-ironman-1936895.pdf

IRONMAN, Engineered for Heroes, Experience the Power of Oracle Cloud.

อืมมมมมม มิน่าล่ะ….

2013-05-03_232616

2013-05-03_234317