[Event] โค้ดชิวๆ: มาคุยเฟื่องเรื่อง Backend กันชิวๆ โดย เครือข่ายโปรแกรมเมอร์ไทย

code-chill

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

ลักษณะเป็น งานโค้ดชิวๆครั้งนี้จะเป็นลักษณะ Lightning Talk คือ แต่ละหัวข้อจะมีเวลา 10 นาที (Setup 2 นาที พูด 8 นาที) โดยมี speaker ทั้งหมด 6 คน มาพูดเกี่ยวกับเทคโนโลยีด้าน Backend ที่น่าสนใจ และอยากหาเพื่อนร่วมพูดคุยในเรื่องนั้นๆกันต่อหลังงาน

เมื่อไปถึงงาน โค้ดชิวๆ

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

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

นอกจากนี้ยังมีกล่าวถึง Project ต่างๆที่ทางสมาคมอยากทำขึ้นเพื่อโปรแกรมเมอร์ไทย เช่น

  • รวมข้อมูล Blacklist , Whitelist, นายจ้าง, ลูกจ้างที่ทำตัวดีและไม่ดี
  • งานช่วยเหลือต่างๆเช่น ระบบถามตอบแบบ stackoverflow ของคนไทย

จริงๆมีเยอะกว่านี้นะครับผมจดไม่ทันจริงๆต้องขออภัยด้วยจริงๆ เอาล่ะตอนไปก็เรื่องงานของ speaker แหละ

โค้ดชิวๆ Speaker 1 A Quick Look at Bigtable

ประวัติผู้พูด: ณัฐวุฒิ กุลนิรันดร (แก๊น), Software Engineer, Google

ปัญหาจากเรื่อง google ต้องการที่จัดเก็บที่สามารถจัดเก็บข้อมูลได้หลากหลาย ต้อง scale ได้และต้องเขียนข้อมูลเร็วด้วย ทางวิศวกรของ google จึงคิดเทคโนโลยีที่ชื่อว่า Big table

โดยเขาอธิบายว่าตัว Big table ก็จะเหมือนกับ Table ทั่วไปเช่น มี แถว ( row ) มีคอลัมส์ ( column ) แต่ column ไม่จำกัดคือเพิ่มได้เรื่อยๆและแต่ละ column ไม่กำหนดว่าเป็นข้อมูลอะไร อาจจะเก็บ text,  object, json, ฯลฯ ได้หมดรูปร่างหน้าตาจะเป็นคล้ายๆอย่างนี้ครับ

bigtable1

โดยตัว column มันจะไม่เหมือน relation table อย่าลืมว่า เพิ่มได้ไม่จำกัด column โดยแต่ละ row จะมี key เฉพาะในการหยิบเหมือนการ query ออกมาครับ และเราก็สามารถเลือกมาเป็นช่วงระหว่างได้

ต่อมาคือจะเป็นความต้องการที่ว่าต้อง scale แบบเครื่องเสียใส่เครื่องใหม่แล้วทำงานได้เลย ความต้องการนี้ตัว Big table มีอีกอย่างหนึ่งที่ทำได้คือ Tablet มันคืออะไร ? ให้คิดว่ามันเหมือนการจัดกลุ่มของตัว row, column เป็นกลุ่มอีกทีดูภาพด้านล่างนะครับ

bigtable2

แล้วในหนึ่งเครื่องจะมีหลายๆ tablet ครับเช่น

bigtable3

สีเทาคือตัว Tablet ที่เป็นกลุ่มครับโดยหากมีการโหลดหนักที่เครื่องไหนเช่น มีการเรียกข้อมูลเยอะๆที่ computer 2 ตัว bigtablet ก็จะสามารถทำลาย tablet ให้น้อยลงและกระจายไปยังเครื่องใหม่ได้ เหมือนเราซื้อ computer เครื่องที่ 3 มาต่อก็จะสามารถ scale ได้ทันทีครับ โดยหลักการคือมันจะทำลาย Tablet ลงแล้วสร้างกลุ่มใหม่ในเครื่องใหม่ ถ้าพูดง่ายๆคือมันทำลายสีเทาแถวที่ 2 ใน computer 2 เหลือ 3 อันแล้ว computer 3 จะมีสีเทา 3 อันทำนองนี้ครับ

ต่อมาคือแล้วจะเขียนเร็วๆได้อย่างไร ? ระบบ Big table จะทำการเขียนข้อมูลลง Ram ก่อนแล้วระหว่างนั้นหากมีการเรียกข้อมูลตัวระบบจะมีตัว compare หรือตัวเปรียบเทียบค่าเพื่อดูว่าข้อมูลใน Ram กับ Harddisk ซ้ำกันไหมแล้วรวมกันเอาข้อมูลส่งออกมาครับ

google ได้ปล่อยตัว cloud bigtable ออกมาซึ่งสามารถทำงานร่วมกับ Hbase ด้วย ( Hbase คืออะไร )

มีเหตุผลอะไรที่ไม่ใช้ Big Table ?

  • ตัว Big table ไม่มี transection
  • ไม่รองรับ SQL

โค้ดชิวๆ Speaker 2 Concurrency with Clojure

ประวัติผู้พูด: ณัฐนาท พรประสิทธิ์สกุล (แท็ป), Developer, groundSWELL

สำหรับ section นี้อธิบายง่ายๆคือการเอา Clojure ( มันคือ ภาษาหนึ่ง อารมณ์เหมือนชื่อ PHP, JAVA ฯลฯ ) มาแก้ไขปัญหาที่เกิดจากการทำงานหลายๆ Process พร้อมๆกัน แล้วเขียนข้อมูลทับกันครับหรือเราจะเรียกปัญหาแบบนี้ว่า Race condition

หากใครงงๆ แล้วไม่รู้ว่ามันคืออะไรสามารถอ่านจาก Link ด้านล่างนี้ได้เลยครับ

โค้ดชิวๆ Speaker 3 Spinal – A Node.js Microservices Framework

ประวัติผู้พูด: ศิระ สัจจินานนท์ (ฮั้นท์), CTO, Jitta

Section นี้พี่ฮั้นท์มาอธิบายถึงตัว Spinal ว่าเกิดขึ้นมาได้อย่างไร และมันดีอย่างไรครับ โดยเริ่มแรกเขาก็อธิบายว่า เวลาเราสร้างเว็บแล้วเราจะมี Model ประมาณนี้

jitta1

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

jitta2

พอมากๆเข้าเป็นไง สมมติเราอยากจะแก้ไข Session ก็จะยากลำบาก ข้อมูลอยู่เครื่องไหนยังไง เริ่มเห็นปัญหาคราวนี้ก็เลยแก้ไขด้วยการแยกมันออกมาเป็น service ต่างๆ ดังนี้

jitta3

แล้วแยกกันเสร็จแล้วก็จะสามารถจัดการได้ง่ายขึ้นแล้วพอวันหนึ่ง session model ทำงานหนักเราก็ทำการเพิ่มตัวจัดการในส่วนของ session อย่างเดียวไม่ต้องไปจัดการทุก model หน้าตามันจะเป็นแบบนี้

jitta4

แล้วก็เอา Load Balance มาจัดการในแต่ละตัวที่เพิ่มขึ้นเช่น session อย่างที่เห็นด้านบนครับ แล้วทีนี้ก็มีปัญหาว่าถ้าตัว Load Balance เยอะมันก็เยอะเกิน เลยเอาไปวางไว้ตัวเดียวแบบจุดตรงกลางของ 4 ตัวก็ไม่ดีอีกเพราะหากตัวกลางตายก็ตายหมด

จึงกลับมาคิดใหม่ว่า ต้องการแบบ centralized และลดความวุ่นวายจึงเกิด spinal ทา ด้า ~~ ( กว่าจะปูมาถึงตัว spinal จะจบแหละ 555 ) โดย model จะเป็นอย่างนี้ครับ

jitta5

หากเราต้องการเขียน a.send() ใน model C ก็สามารถทำได้เลยมีตัวจัดการกลางไปเรียก model a method send() ตัว Broker นั่นแหละครับ โดย Feature มันมีประมาณนี้ครับ

  • Real time dashboard
  • Real time stat
  • Rest API
  • Job Queues
  • caching

แล้วกำลังทำอยู่มีอีกหลายอย่างเลยสามารถไปดูได้ตามนี้เลยครับ https://github.com/jitta/spinal

โค้ดชิวๆ Speaker 4 DevOps life with Docker

ประวัติผู้พูด: จิรายุส นิ่มแสง (เดียร์), The Builder, Kaidee.com

Section นี้จะมาพูดถึง Docker เอาง่ายๆคือตัวจัดการให้ Enviroment ต่างๆของเครื่อง Dev กับ Server นั้นเหมือนๆกัน โดยบางครั้งหากจัดการเรื่องเขียนโค้ดแล้วเอาขึ้น Server จริงมันช้า มันรันได้ไม่เหมือนกัน

ตัว Docker ก็เหมือน VM แต่ไม่กิน Ram เหมือนตัวอื่นเช่น หากเราเปิดใช้ apache ใน VM ใช้ Ram 300 MB มันก็ใช้แค่ 300 MB ไม่ใช่แบบเรากำหนดไว้ 1 GB มันก็กินหมดไรเงี้ย

ข้อดีอีกอย่างคือ เราสามารถสร้าง Template ของ Env จากต้นแบบแล้วส่งไฟล์นั้นให้ Dev ไปรันในเครื่องตัวเองแล้วได้ Env เหมือนกันชีวิตดีขึ้นเยอะและสามารถ set พวก test เข้าไปด้วย

มีการพูดถึง Deloy Production Zero downtime โดยใช้วิธี Blue Green Deloyment หลักการคือ กั้นไม่ใช้คนเข้าใช้งานในตัว server ทีละตัวเช่นมีเครื่อง A, B, C ก็จะกั้นการเข้าใช้งาน A ก่อนแล้วทำการ Deploy ลงในเครื่อง A ระหว่างนั้นก็จะมีไฟล์เก่าของ A ด้วยเก็บไว้จนกว่าจะทำการ Deloy เสร็จแล้วก็ทำเหมือนเดิมในตัวต่อไปครับ

docker1

โค้ดชิวๆ Speaker 5 บนท้องฟ้ามีกลุ่มเมฆ ในกลุ่มเมฆมี AWS

ประวัติผู้พูด: ดร.วิชญ์ เนียรนาทตระกูล (วิช), CTO, Stamp

Section นี้พูดถึง AWS เป็น cloud ของ Amazon เวลาเราจะเขียนโปรแกรมเอาขึ้นไป ต้องคำนึงถึงอะไรบ้าง และมันปลอดภัยไหม การเลือกใช้งานแต่ละตัวของ AWS ต้องคิดถึงอะไรหลักๆมีเท่านี้ ที่เหลือเป็นการพูดถึงตัวโปรแกรมของ Stamp ไปว่ากันเรื่อง AWS ก่อนแล้วกันครับ

  • เวลาเลือกเครื่องที่จะใช้งานก็ต้องดูช่วงเวลาการใช้งานของ User ด้วยถ้าเยอะช่วงไหนก็สั่งให้มันเปิด instance เพิ่มขึ้นมากล่าวคือ เหมือนเราเพิ่ม Ram เพิ่ม Harddisk ให้เหมาะสมกับช่วงเวลาถ้าใช้น้อยก็ปิดไป
  • AWS มีความปลอดภัยแม้แต่ตัว Engineer ที่ทำงานก็ไม่รู้ว่าข้อมูลของใครอยู่ตรงไหน ยิ่งคนไม่เกี่ยวข้องจะไม่มีสิทธิ์ได้เข้าถึงข้อมูลอย่างแน่นอน
  • เวลาเขียนโปรแกรมต้องคำนึงการขยายในทางแนวนอน เหมือนการเพิ่มเครื่องเลย เพราะการเพิ่ม Ram ถึงจุดหนึ่งก็เต็ม
  • เลือก Cloud ให้เหมาะสมกับงานที่ใช้เช่น หากเราจะใช้เก็บรูปก็ควรเลือก S3 เพราะรองรับการอ่านบ่อยๆ

โดยหากใครต้องการติดตามข่าวสารก็มี Group อยู่ด้วยตาม Link ด้านล่างเลยครับ

https://www.facebook.com/groups/awsusergroup/

แล้วก็มีงานที่จะจัดใกล้ๆนี้ด้วยใครสนใจเชิญ

http://aws.amazon.com/events/awsome-day/thailand-01/

โค้ดชิวๆ Speaker 6 Scalable Architecture Pitfalls

ประวัติผู้พูด: วโรกาส ภาณุสุวรรณ (นน), ผู้เขียนหนังสือ Agile Pitfalls

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

pillfail1

อารมณ์ประมาณนี้ ผู้พูดให้คำแนะนำว่าเวลาเราคิดระบบอะไรใหญ่ๆ อย่าไป Design ใหญ่ๆ ให้ทำเล็กๆแต่ปั้มออกมาได้จาก 1 เป็น 2 จาก 2 เป็น 4 เขาบอกว่า การออกแบบระบบอ่ะง่าย ถ้าเรารู้ตัวเองว่าเราต้องการอะไร แต่ … ส่วนใหญ่เราก็ไม่รู้ต้องการอะไรแล้วก็ทำๆกันไปฮ่าๆ

แล้วก็มีบอกว่าด้วยว่าในการออกแบบมี 3 ตัวเลือกหลักๆที่เราต้องคำนึงถึง อารมณ์ว่าหากเรามี 100% เราจะแบ่งให้ส่วนไหนใน สามส่วนนี้ ถ้าแบ่งให้อันแรก 50% ก็ต้องทำใจว่าอีกสองอันมันจะห่วย ประมาณนี้ 3 ข้อนั้นมีดังนี้

  1. ทำงานได้หลายๆตัวพร้อมกัน
  2. ตอบสนองได้รวดเร็ว

อันที่สามจำไม่ได้จริงๆนะครับ ใครจำได้ก็ตอบ comment ให้หน่อยนะครับประมาณนี้

สรุป โค้ดชิวๆ

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

https://www.facebook.com/groups/ThaiPGAssociateSociety/

หากคุณชอบข่าวสารของ Blog นี้อย่าลืมกรอกรับข่าวสารในหน้าแรกหรือ Like fan page ได้ที่

https://www.facebook.com/Tong.oxygenyoyo

 

  • m3rlinez

    เก็บรายละเอียดได้เยอะมากเลยครับ ผมพยายามอัดให้ได้ใน 8 นาที ต้องตัดและข้ามไปหลายเรื่องเลย ถ้าสนใจมีรายละเอียดลึกกว่านี้ใน slide นี้นะครับ

    //research.google.com/people/jeff/SOCC2010-keynote-slides.pdf

  • Mapon Pum

    โอ้วจดไว้ละเอียดเลย ^^ ขอบคุณครับ

  • Supasate Choochaisri

    ดีมากเลยครับ ขาด Bonus Speaker ไปอีกคนนึง ธีระพล วัธนเวคิน (เอ), Software Engineer, Google Thailand หัวข้อ “Build Private Cloud – High Performance but Low Cost ” ครับ

  • oxygenyoyo

    section นั้นผมจดมา 4 บรรทัดเองครับเกรงว่าเขียนไปไม่ได้มีเนื้อหาอะไรเลยครับเลยไม่ใส่ดีกว่าครับ

  • oxygenyoyo

    ยินดีครับที่ชอบ

  • oxygenyoyo

    ขอบคุณครับ