งานใหญ่สำหรับชาวโปรแกรมเมอร์ไทยครั้งแรกของปีนี้! จัดเป็นครั้งที่ 3 แล้ว มีคอนเซปคือ Raise the Bar โดยสมาคมโปรแกรมเมอร์ไทย ซึ่งตอนนี้ทีมงานเค้าได้จดทะเบียนใช้ชื่อสมาคมอย่างเป็นทางการเป็นที่เรียบร้อย แล้วก็มาเปิดตัวในงานนี้ด้วย มีวัตถุประสงค์หล่อๆ ตามนี้
- พัฒนาทักษะ
- สร้างเครือข่าย
- ยกระดับภาพลักษณ์
- ช่วยเหลือนักพัฒนาและผู้ว่าจ้าง
- สร้างพื้นที่และโอกาสใหม่ๆ
- สนับสนุนและจัดกิจกรรม
ถือว่าเป็นข่าวดีสำหรับวงการโปรแกรมเมอร์เมืองไทยเลยนะ สู้ๆ นะครับ ร่วมกันพัฒนาวงการนี้ไปด้วยกัน 🙂 ใครสนใจสมัครสมาชิกก็ติดต่อไปเลยนะครับ สมัครง่ายได้ผลประโยชน์เพียบ! จบช่วงโฆษณา.. ว่าแล้วก็เขียนบอกเล่าสิ่งที่ไปฟังมาบ้างดีกว่า ขอเขียนแค่บางประเด็นนะครับ ใครอยากฟังเต็มๆ คอยติดตาม Thai Programmer Network ทาง YouTube กันเอานะ ส่วนพวกสไลด์ต่างๆ ตามเก็บได้ที่ Code Mania 11 : Raise the bar
Wongnai Engineering Story
โดย ภัทราวุธ ซื่อสัตยาศิลป์ (บอย) จาก วงใน
วันนี้ CTO ได้สละเวลามาแบ่งปันประสบการณ์และเรื่องราวตั้งแต่เริ่มต้นทำ Startup ว่ามีความเป็นมาอย่างไรบ้าง เจอปัญหาอะไรบ้าง ตั้งแต่คอมพิวเตอร์เครื่องแรกยันย้ายระบบไปไว้บน cloud อย่าง AWS ส่วนประเด็นที่น่าสนใจสำหรับผมมีตามนี้
- ใช้ Amazon SES ในการส่งเมล มีข้อดีคือ สามารถส่งเมลได้ up to 90 emails/sec แล้วก็ email ที่ส่งจะอยู่ใน whitelist
- สำหรับระบบของ Wongnai การแยก select แต่ละ table แล้วเอามา join เองมี performance ที่ดีกว่าปล่อยให้ join ในระดับฐานข้อมูล
- RDS มี IOPS จำกัด เวลา migrate data เยอะๆ แล้ว อาจจะต้องระวังค่า IOPS อาจจะมีไม่พอ จะทำให้ระบบล่มได้
- ใช้ Apache Solr สำหรับการ search แต่ติดปัญหาเรื่อง real-time indexing ตอนนี้ใช้วิธีเพิ่มอีก layer หนึ่งมาทำ batch processing ในการ reindex
- ทั้งๆ ที่ใช้ AWS อยู่แล้ว ทำไมถึงไม่ใช้ Elasticsearch บนนั้นด้วยล่ะ? อันนี้เป็นเพราะเค้าไม่อยากยึดติดกับ AWS มากเกินไป เผื่อในอนาคตอาจจะย้ายไปที่อื่นแทน
Like Behaviour on Facebook Pages
โดย ณรงค์ อินทร์รักษ์ (โหน่ง) นิสิต ป.เอก จุฬาฯ
คุณโหน่งกำลังทำวิจัยเกี่ยวกับการกด like บน page แต่ละประเภทว่าแตกต่างกันอย่างไรในช่วงเวลาต่างๆ ข้อมูลจาก Facebook ไม่ได้บอกว่า คนเข้ามากด like ตอนไหน เลยเขียน bot ขึ้นมาเพื่อดูจำนวน likes (คอย poll ดูเรื่อยๆ) แล้วก็ดูช่วงเวลาเอง ส่วน data visualization ใช้ Tableau มาวิเคราะห์ช่วงเวลาในแต่ละวัน แต่ละชั่วโมง แบ่ง page เป็นแต่ละ category แล้วลิสต์ออกมาดูว่าแต่ละ category มีช่วง peak เป็นอย่างไรบ้าง
ใครสนใจอยากลองดึงข้อมูลจาก Facebook ก็ลองดู Facebook Graph API นะครับ
Hello! Functional Programming
โดย ศุภณัฐ โพธิวรากร (บอส) นิสิตปี 4 จุฬาฯ
เนื่องจากได้ลองเขียนภาษา Scala (an object-functional language) แล้วติดใจ เลยหันมาสนใจ Functional Programming แล้วก็เอาไปทำโปรเจคจบด้วย ข้อดีของ Functional Programming ก็ประมาณนี้
- โค้ดเขียนแล้วเข้าใจได้ง่ายขึ้น มองแล้วเข้าใจว่าจะเกิดอะไรขึ้น การเปลี่ยนแปลงหรือการแก้ค่าตัวแปรจะเกิดภายในฟังก์ชั่นเท่านั้น
- เทสง่าย เพราะว่าฟังก์ชั่นเป็น deterministic
- ทำ parallel ง่าย
การเขียนโปรแกรมแนวนี้จะหลีกเลี่ยงการเกิด side effect ถ้าหลีกเลี่ยง side effect ไม่ได้ ก็ควรจะพยายามทำให้ function ของเรามัน idempotent แล้วก็พยายามแยกให้แต่ละ state ให้แบ่งกันได้ชัดเจน
Test Double Patterns with Python
โดย ณัฏฐณิชา ภัทรมาลัย (เก๋) จาก #prontotools
Speaker สาวคนเดียวในช่วงเช้า มาพร้อมกับเรื่องของ Test Double ที่เป็นคำที่มาจาก Stunt Double ที่ใช้คนแสดงแทนในฉากที่อันตรายๆ ส่วน Test Double เราก็ใช้ตัวที่สามารถทดสอบได้แทน โดยไม่ต้องไปทดสอบบน Production
คำว่า Test Double เป็นอีกคำหนึ่ง คนส่วนใหญ่จะรู้จักในคำว่า Mock กัน มี 5 แบบ
- Dummy จะประมาณว่าเราสร้าง dummy object มา แล้วโยนใส่เข้าฟังก์ชั่นไปเพื่อให้ฟังก์ชั่นนั้นรับอากิวเมนต์ให้ครบๆ แต่ dummy object นั้นไม่ได้เอาไปทำอะไรต่อ
- Stub ประมาณว่าถ้าเราจะทดสอบระบบหลังจากที่เรา login ไปแล้ว ว่าเกิดอะไรขึ้นบ้าง แต่เราไม่อยากจะเขียนให้มีการ login จริงๆ ในการทดสอบ เราก็ stub ส่วนนั้นไว้ ทำให้เราสามารถทดสอบส่วนอื่นๆ ได้
- Spy เป็นการพยายามที่จะ record ตัวแปร หรือจำนวนครั้งในการเรียกฟังก์ชั่นที่เราต้องการจะทดสอบ
- Mock เป็นการดูพฤติกรรมของฟังก์ชั่นที่เราต้องการจะทำสอบ เช่น ถ้ามีฟังก์ชั่นหนึ่งเรียก API แล้วเราอยากรู้ว่าฟังก์ชั่นนั้นจะเรียก API ถูกหรือเปล่า ส่งค่าไปถูกต้องหรือเปล่า ในกรณีนี้เราจะใช้ Mock
- Fake ยกตัวอย่างกรณี in-memory database เช่นในสภาพแวดล้อมของการทดสอบเราจะใช้ SQLite ส่วนในสภาพแวดล้อมบน production เราจะใช้ PostgreSQL เป็นต้น
ในชีวิตจริงนั้น สำหรับผมแล้วที่ใช้บ่อยๆ ก็เห็นจะมี Stub Mock และ Fake ใครสนใจอ่านเรื่องนี้ต่อ เชิญอ่านที่
- Test Double โดย Martin Fowler
- Mocks Aren't Stubs โดย Martin Fowler
- The Little Mocker โดย Robert Martin (Uncle Bob)
Programming as a Sport
โดย ภัทร สุขประเสริฐ (แอ้ม) จาก Google
..ลืมถ่ายรูป -/\-..
ได้มีโอกาสเข้าไปฟัง เพราะอยากได้ช่องทางการฝึกฝนตัวเอง เค้าไม่แนะนำว่าการฝึกทำโจทย์เก่าๆ เพราะว่าจะต้องทำคนเดียว แล้วก็จัดการเวลายาก เลยเสนอเว็บให้ไปลองเข้าไปแข่งดู
สำหรับผมแล้วตัว HackerRank นั้นน่าสนใจกว่า เพราะว่าเป็นโจทย์ที่บริษัทต่างๆ ให้มาช่วยแก้ปัญหา แล้วก็เหมือนเป็นการ recruit คนไปในตัว เป็นโอกาสให้เราได้แสดงความสามารถให้กับบริษัทที่เราสนใจได้เห็น 🙂
แล้วการคิดการหา Solution ตอนแข่งล่ะ?
- ก่อนอื่นให้พยายามอ่าน input กับ constraint ที่ได้มาให้ดีก่อน ทำความเข้าใจกับมันให้ดีๆ ก่อนไปนึกถึงเรื่อง Big O
- ลองหา specific solution มาก่อน เช่น ถ้าเป็นเรื่อง graph ให้ลองใช้ DAG ดู ถ้าแก้ปัญหาได้ค่อยขยับไปก้าวต่อไป
- ลองพวก data structure กับ algorithm ที่เรารู้จักก่อน
- การตรวจสอบผลก็สำคัญเช่นกัน เราคงไม่อยากจะส่งโค้ดแบบผิดๆ ไป ดังนั้นเราควรสร้างเทสเคสออกมา วิธีสร้างก็อาจจะ brute force ให้ได้ผลออกมาเป็นตัวเทียบ
Take a REST
โดย สินาภรณ์ สืบวิสัย (พี่แป๋ม) จาก Proteus
Speaker สาวคนเดียวช่วงบ่าย (งานนี้มี Speaker สาว 2 คน ทีมงานสมาคมหามาเพิ่มด่วนนะ ติดต่อ Girls Who Dev ได้ :P)
หลายๆ คนรู้จัก REST ในมุมของ API แต่จริงๆ แล้วจุดเริ่มต้นของ REST เค้าออกแบบมาเป็น architectural style เริ่มต้นมาจากงานวิจัยของ Roy Thomas Fielding ลองไปอ่านรายละเอียดกันดูนะครับ เงื่อนไขที่ก็จะประมาณนี้
- เป็น Client-server
- Stateless คือแต่ละ request จะต้องแยกจากกันชัดเจน แต่ละ request ต้องไม่ขึ้นต่อกัน
- Cache เรื่องนี้คนส่วนใหญ่มักจะคิดเป็นเรื่องท้ายๆ ซึ่งจริงๆ สำคัญในการ scale ระบบมาก
- Uniform interface ก็ทุกคนคุยกันด้วย HTTP protocol
- Layered system คือประมาณว่าเราระบบมีหลายชั้น ซึ่งแต่ละชั้นสามารถแยกออกจากกันได้ แต่ละชั้นไม่ควรจะรู้ว่าชั้นบนหรือล่างมันทำงานอย่างไร
- Code-on-demand อันนี้ประมาณว่า client สามารถเลือกได้ว่าอยากใช้ API code version อะไร แล้ว server ก็จะตอบ version นั้นกลับมา ตรงส่วนนี้ดูเป็น optional
เรื่องการออกแบบล่ะ?
- ควรจะอ่านแล้วรู้เลยว่าตอน request ไป แล้วจะได้ response อะไรกลับมา เช่น ส่ง request ไปยัง
/booksเราก็ควรจะได้หนังสือทั้งหมดกลับมา การใช้ slug เป็น resource หรือ URI จะดู user friendly มากกว่าแบบที่ส่งไปเป็น query string - ตัว data representation นี่เป็นแบบไหนก็ได้นะ XML หรือ Text ธรรมดาก็ได้ แล้วแต่ตกลงกัน ซึ่งส่วนใหญ่จะใช้ JSON เพราะง่าย แล้วก็ lightweight
Idempotent คือ?
ถ้าอ่านเรื่องที่เกี่ยวกับ REST จะเจอคำๆ นี้บ่อย คำว่า idempotent เนี่ย พี่แป๋มยกตัวอย่างได้จุดแสงสว่างให้ผมได้ทันที กราบ คือประมาณว่า ไม่ว่าจะส่ง request ไปกี่ครั้งยัง server จะไม่ทำให้ state ของ server เปลี่ยน เราสามารถ retry ไปกี่ครั้งก็ได้ เช่น การส่ง GET ไปยัง server ตัว server ก็แค่ส่ง response กลับ ไม่มีการเปลี่ยนแปลง state อะไร แปลว่า GET เนี่ยเป็น idemponent นะ ส่วน POST นี่ไม่ใช่ เพราะ POST เป็นการส่งไป create ส่ง request ไปแต่ละครั้งจะไปสร้างอะไรบางอย่างบน server ทำให้ state ไม่เหมือนเดิม
Navigational links เป็นส่วนที่ไม่ค่อยมีคนพูดถึง แต่ว่ามีประโยชน์ ที่น่าจะเห็นกันบ่อยๆ ก็พวก API ที่ทำ pagination เพราะว่าไม่สามารถส่ง data ออกมาทั้งหมดได้ ทีนี้ก็จะส่งลิ้งค์สำหรับหน้าต่อไปมาให้ client แล้วก client ก็สามารถเอาลิ้งค์นั้นไป GET ต่อได้
การใช้ REST มีข้อดีในการ scale ด้วย เวลาเราออกแบบเราควรจะทำให้แต่ละ resource แยกออกจากกัน เราจะได้ scale บาง resource ได้ เช่น ถ้าคนส่วนใหญ่ใช้ /accounts แต่ไม่ค่อยใช้ /accounts/xxx เราก็สามารถ scale แต่ /accounts ได้
ความยากของการออกแบบ REST
- มันไม่มีผิดไม่มีถูก "no one right way"
- Separation of concerns คือเป็นเรื่องยากที่จะออกแบบให้มัน loose coupling ได้ดีๆ มันจะมี trade-off อยู่ในเชิงปฏิบัติ
- Authentication กับ Authorization เรื่องนี้ต้องคิดเพราะว่าบางทีเราไม่แน่ใจว่าควรจะเป็น per service หรือว่าแบบ centralized ดี
- Deployment needs automation เราต้องคิดว่าเราจะ deploy อย่างไรด้วย ให้โค้ดของเราเหมือนกันทุก server ซึ่งการ deploy อะไรบางอย่างไม่ใช่แค่ว่าเราเอาโค้ดขึ้นไป จะมีเรื่องของ service ต่างๆ มาเกี่ยวข้อง
- Defining cache contents เรื่องนี้เป็นเรื่องยากของโปรแกรมเมอร์อยู่แล้ว ที่ว่าเราจะ cache อะไร เรื่องนี้เลยมาหลอกมาหลอนในส่วนนี้ด้วยที่ว่าเราต้องดูว่า resource ไหนโดนเรียกบ่อย และ resource นั้นส่ง response ที่ต่างออกไปจากเดิมบ่อยแค่ไหนด้วย ถ้าไม่ค่อยเปลี่ยนแปลงอะไรมากเราก็ควรจะ cache ตรงจุดนั้น แต่ก็จะมีประเด็นเรื่องเราจะ cache ไว้นานเท่าไหร่อีก
REST เนี่ยมันมันทำให้ service เนี่ย loose coupling นะ แล้วก็ไปได้ดีกับเทรนด์ Microservice เลยทีเดียว ใครอยากทำแนวนี้ก็ควรศึกษาไว้ครับ 😉
Building and Maintaining OpenSource Projects
โดย อัครวุฒิ ตำราเรียง (บัง) จาก Marvelic Engine
ส่วนใหญ่แล้วคนที่ทำ open source จะอยู่ไม่ค่อยได้ เพราะไม่ได้สิ่งตอบแทน โดยเฉพาะ "เงิน" 🙂 คนเราก็ต้องกินข้าวเนอะ ทีนี้พี่เค้าก็เลยมาเล่าว่าพี่เค้าทำอย่างไรบ้าง มีส่วนใน community ของ Joomla! อย่างไร เงินหาจากไหน อะไร อย่างไร
ก่อนที่จะเริ่มต้นงาน open source เราควรจะต้องเข้าใจเรื่อง license กับ copyright ก่อน เป็นเรื่องที่สำคัญมาก เราจะได้รู้ได้เข้าใจว่าสิ่งที่เราทำมีขอบเขตแค่ไหน ใครสามารถเอาไปทำอะไรต่อได้บ้าง license นั้นมีหลายแบบมากครับ ลองเข้าไปดูใน Opensource.org
เรื่องการสร้าง community เราสนับสนุนคนที่เข้ามาทำมีความรู้สึกว่าเป็นเจ้าของผลงาน ถ้าส่งเสริมให้เค้ารู้สึกแบบนั้นได้ เค้าก็จะมีส่วนร่วมมากขึ้น เรื่องช่องทางการสื่อสารก็เป็นสิ่งจำเป็น ต้องกำหนดช่องทางกันดีๆ สามารถพูดคุยกันได้ ปัญหาที่เกิดขึ้นมีไหม? มีแน่นอน การทำงานร่วมกับคนอื่นจะมีดราม่าหรืออะไรต่อมิอะไรที่เราอาจจะคาดไม่ถึง แน่นอนเราสามารถลดตรงนี้ได้โดยการพูดคุยกัน
การเข้าร่วมใน Joomla! community ล่ะ? มี 3 ขั้นตอนง่ายๆ ครับ
- เข้าไปร่วมใน issue tracker ไปพูดคุย ไปร่วมทดสอบ จริงๆ แค่ไปร่วมทดสอบก็มีชื่อขึ้นใน release นั้นๆ แล้วนะ
- ส่ง patch เข้าไปแก้
- มีคนช่วยทดสอบ patch นั้นอย่างน้อย 3 คน
เรื่อง Event ต่างๆ ที่จัดขึ้นก็จะหาสปอนเซอร์มาร่วม หรือไม่ก็คนใน community ช่วยกันออกเงินเอง ฟังดูแล้วน่ากลัวเนอะ แต่จริงๆ แล้วเนื่องจากผู้ใช้งานเยอะ มีคนมาร่วม contribute เยอะ การหาเงินสนับสนุนแบบนี้ไม่น่าจะมีปัญหาเนอะ
พี่เค้าเล่าอีกว่าเค้าเจอ Matt คนทำ WordPress ที่งาน Joomla! ด้วย แล้วก็เล่าประมาณว่า community เมืองนอกเค้าสนับสนุนกัน ของ Joomla! ก็มีการเชิญคนจาก WordPress ไปพูด เป็นการแบ่งปันไอเดียกัน น่าสนใจ น่าสนใจ
Functional Reactive Programming
โดย ศอลาฮุดดีน เฉลิมไทย (พี่ดีน) จาก Thoughtworks
ปัจจุบันบน Web-based application มีการทำ asynchronous เยอะมาก ซึ่งก็มีปัญหาตามมาอีกพอสมควร อย่างเช่น
- Memory leak เนื่องจากมีการ subscribe ไว้ แต่ไม่เคย unsubscribe เลย
- Race condition คือการที่มีหลาย thread เข้าไปแก้ไขข้อมูล
- เกิด callback hell ประมาณว่าเรียกซ้อนกันไปเรื่อยๆ
- มี state machine ที่ซับซ้อน
- การทำ error handling อาจจะไม่คุ้นชิน เพราะว่าต้องทำเป็น callback ไม่เหมือนกับทำ try catch แบบที่เราเคยทำกัน
คอนเซปของ Reactive programming ก็ประมาณว่าถ้าเรามีสมการ A = B + C โดย A จะขึ้นอยู่กับ B และ C ถ้าเราเปลี่ยนค่า B กับ C แล้ว A ก็จะเปลี่ยนตาม ซึ่งถ้าเขียนโปรแกรมแบบปกติแล้วจะไม่เป็นตามนั้น ยกตัวอย่าง
b = 10 c = 5 a = b + c # ได้ a มีค่า 15 b = 11 # จังหวะนี้ a ก็ยังมีค่าเท่ากับ 15 ไม่ได้เปลี่ยนไปตาม b
Reactive programming ยังได้นำเอาส่วนดีของ Iterator กับ Observable pattern มาใช้ร่วมกัน ทำให้กลายเป็นการนำเอามาใช้กับ data streaming อย่างเช่น event ที่เข้ามาเรื่อยๆ เป็น sequential ได้อย่างลงตัว อีกทั้งการที่มันเป็น functional programming ก็ทดสอบ การเขียนโค้ด ก็จะดูเข้าใจง่าย และตรงไปตรงมา
พี่เค้าแนะนำเว็บสำหรับเข้าไปดูการทำงานของ Reactive programming ครับ ชื่อ RxMarbles สุดยอดเลย (-/\-)
ทีนี้ case study ที่พี่ดีนยกเอามาพูดเป็นกรณีของ Netflix ครับ เป็นเพราะว่าที่นี่มี architecture แล้วก็ทำ Reactive ได้แจ่ม ชี้เป้าให้ลองไปตามดู Asynchronous JavaScript at Netflix ของ Jafar Husain สำหรับคนที่สนใจครับ
จบวัน ปิดงาน 🙂
คนมาเพียบเลย ขอบคุณพี่ๆ เพื่อนๆ น้องๆ ที่มาทักทายกันครับ ใครพลาดนี่น่าเสียดายมากนะ ครั้งต่อๆ ไปห้ามพลาดนะครับ เพราะมันจะดีขึ้นเรื่อยๆ ผมมั่นใจแบบนั้น 🙂
สุดท้ายกราบขอบคุณทีมงานสมาคมโปรแกรมเมอร์ไทยทุกคน จัดต่อไปเรื่อยๆ นะครับ!
