Tag Archives: Ruby

เรื่องสำคัญที่หนังสือ OOP ทั่วไปไม่ได้สอน

ดัดแปลงจาก Facebook โพสนี้ https://www.facebook.com/nuttanart/posts/10154374407186081

ซึ่งเป็นโพสต่อเนื่องจากโพสแนะนำหนังสือ 99 Bottles of OOP อันนี้ https://www.facebook.com/nuttanart/posts/10154374324641081

ถึงแม้ผมจะเชียร์หนังสือ 99 Bottles of OOP อย่างไร ผมยังรู้สึกว่ายังมีปัญหาสำคัญมากๆ อันหนึ่งที่ทำให้โค้ดเราเน่าและหนังสือเล่มนี้คงจะไม่ได้พูดถึง หนังสือเล่มอื่นๆที่ผมเคยได้อ่านมาก็ไม่ได้สอน คือ การอยู่ร่วมกันระหว่าง OO กับสิ่งเหล่านี้
– การเชื่อมต่อ database
– การทำ external call
– logging
– อ่าน/เขียนไฟล์
– UI
– ฯลฯ

อาจจะมีแนวคิด Clean Architecture ที่พูดถึงอยู่บ้าง เพียงแต่ว่างบางครั้งเราไปโฟกัสที่ตัว pattern และแต่ละ component มากเกินไปจนลืมว่าจริงๆ แล้วต้นเหตุของปัญหาของเราคืออะไร

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

บางคนอาจจะคิดในใจว่า นี่มัน side-effects นี่หว่า ใช่แล้วครับ ผมคิดว่าอีกปัจจัยหนึ่งที่จะทำให้เราเขียนโค้ด OO ได้ดี ดันเป็นสิ่งที่ OO ไม่ได้สอน แต่มันอยู่ในแนวคิด functional programming ถ้ารู้ว่าจะจัดสิ่งเหล่านี้ให้อยู่ถูกที่ถูกทางได้อย่างไร มันจะทำให้เราจะมีพื้นที่ให้จัดโค้ด OO ให้ดีได้

ลองไปศึกษาเรื่อง side-effects ดูนะครับ แล้วจะพบว่าหลายๆ ปัญหาที่เราเจอกันอยู่ สาเหตุเกิดจากพวกมันนี่แหละ

Update: talk นี้อธิบายเพิ่มเติมได้ดีว่า side-effects คืออะไร และมันสำคัญอย่างไร

Sandi Metz at Keep Ruby Weird 2015 – Be Yourself

“In order to make a best group we can be, then each of you have to act as you are the only one here.”

งานนี้ Sandi Metz เป็น keynote speaker เลยไม่ได้พูดเรื่องโค้ด แต่พูดในลักษณะให้แนวคิดแก่ community และเซต theme งาน

เธอเล่าถึงการทดลองเกี่ยวกับพฤติกรรมมนุษย์ 3 ชิ้น
Asch conformity experiments, Milgram experiment, Latané and Darley(Bystander effect)

แนะนำให้ใส่หูฟังๆ เพราะคุณภาพการอัดเสียงของ video นี้ไม่ค่อยดีเท่าไหร่

ต่อไปนี้จะเป็นการ spoil สิ่งที่ Sandi สรุปจากการทดลอง ดู/ฟังการทดลองก่อนจะสนุกกว่านะครับ

จาก Asch:

  • ถ้าอยากให้กลุ่มคนเห็นพ้องต้องกันเรื่องอะไร ให้ทุกคนพูดความเห็นของตัวเองออกมาตรงๆ โดยให้กลุ่มคนที่ตำแหน่งใหญ่กว่าพูดก่อน
  • ถ้าอยากได้ความหลากหลายทางความคิด ให้คนเขียนความเห็นลงกระดาษก่อน ก่อนที่จะพูดออกมา และให้ทุกคนได้พูดในเวลาที่เท่าเทียมกัน

จาก Milgram:

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

จาก Latané and Darley

  • ถ้าต้องการให้ไม่มีใครตอบสนองคำขอร้อง ให้ขอโดยตรงจากกลุ่ม
  • ถ้าต้องการให้มีคนตอบสนอง ให้ขอไปที่คนโดยตรง

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

“Not conforming with the Group. Be yourself.”

ทำไมผมถึงสนใจ Clojure

พี่รูฟ ถามว่าทำไมผมถึงไม่ใช้ JRuby (ในคอมเมนต์) แล้วผมเขียนตอบไว้ซะยาวเลย เลยขอมาแป๊ะไว้ที่นี่ด้วยๆ ความเสียดาย ด้านล่างนี้คือคำตอบของผม

ไม่รู้สิครับ ไม่ได้อยู่ในการตัดสินใจเลย

ในตอนเริ่ม ทีมมีคนถนัด Ruby กับคนถนัด JavaScript แต่คนทั้งสองกลุ่มตื่นเต้น และอยากเขียน Clojure ก็เลือกกันโดยไม่มีใครมีข้อขัดแย้ง อ่อมันใช้เขียนถอด data format แปลกๆ ของโรงบาลได้ง่ายกว่าด้วย

ส่วนตัวผมทำไมถึงสนใจ หลักๆ ก็คืออยากเปลี่ยนบรรยากาศอะครับ
– เบื่อเขียน class (Kingdom of nouns)
– อยากลองศึกษาว่าข้อดีของการแก้ปัญหาด้วย functional concept เป็นยังไง
– ชอบ persistent data structure มาก ทำให้ไม่รู้สึกผิดเวลาใช้ map, reduce, select, ..
– collection library มันหล่อมาก
– อยากลอง REPL driven development ที่เค้าว่าเร็วๆ เป็นยังไง
– อยากเขียน concurrent programming บ้าง
– ภาษามันไม่เยิ่นเย้อ สั้น แต่ชัดเจน

จากนั้นก็เล่าถึงข้อเสียให้ฟัง

ข้อเสีย
– Startup time ช้า start JVM ปกติเสร็จแล้วยังต้องโหลด standard lib ต่ออีก ปกติ dev บน REPL ก็ไม่เป็นอะไร แต่ถ้าต้องแก้ config หลักๆ บางครั้งก็ต้อง restart
– ต้องรู้ Java ด้วย อ่าน error ได้ เรียกใช้ Java library ได้
– (ตามการคาดเดาของผม) ไม่มีวัน mainstream
— อธิบายให้คนฟังว่า prefix notation ไม่ได้ยากกว่า infix notation นี่ไม่ค่อยจะมีใครเชื่อ และเข้าใจง่ายๆ
— การนับวงเล็บปิดมันไม่ง่าย มี tool ช่วยถ้าใช้เป็นแล้วจะลืมวงเล็บปิดไปเลย แต่ก็ต้องเรียน (เหมือนเรียน vim command)

จากคำถามของพี่เค้าทำให้คิดย้อนกลับไปถึงสาเหตุจริงๆที่หัด Clojure

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

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

เย่!

สรุป The Recipe for the World’s Largest Rails Monolith

เค้าว่าระบบเค้าเป็น Rails app ที่ใหญ่สุดในโลก มาเล่าเรื่องการ scale ให้ฟังอย่างสนุกสนาน
– เขียน auto scaling
– เขียน deploy tool ใหม่
– เขียน activerecord adapter สำหรับ connect multiple databases
– เขียน tool สำหรับเอา spec ไปรันบน aws spot instance
– เขียน database cleaner ใหม่สำหรับ clean เฉพาะ table ที่ถูกแตะตอน test
– เขียน database migration tool ใหม่
– เขียน component framework ใหม่
– เริ่มเขียนปี 2007 ตอน rails 1.x, upgrade มาเรื่อยๆจนตอนนี้ 4.1 แล้ว upgrade โดยการทำ shadow server เปรียบเทียบ output ของ version เก่าและใหม่

ตัวอย่าง source code โปรเจ็ค Rails ที่น่าสนใจ

Ben Orenstein พนักงาน thoughtbot ที่เคยพูดเกี่ยวกับ refactoring ที่งานต่างๆ หลายครั้ง ร่วมมือกับ Chris Hunt พนักงาน Github เขียน web application ที่ชื่อว่า Trailmix ขึ้นมาแทนบริการที่เค้าชื่นชอบที่ชื่อว่า OhLife ซึ่งได้ปิดตัวลงไป

เค้าได้เปิด source เจ้า Trailmix นี้ด้วย จากที่ดูคร่าวๆ ผมว่ามันเป็นโปรเจ็คตัวอย่างที่ดีมากสำหรับ Rails application ทั้งเรื่อง design, testing และที่สำคัญมันเป็น application ที่มีผู้ใช้งานจริงและเก็บเงินจริง ซึ่งปกติจะไม่มีใครยอมเปิด source code กัน ในส่วนท้ายของ Readme ยังระบุถึง practice และ guideline ต่างๆ สำหรับโปรเจ็คโดย link มาจาก guideline ของ thoughtbot ด้วย

ใครที่อยากดูตัวอย่างว่าจะเขียน Rails app ดีๆ ต้องทำยังไง โปรเจ็คนี้น่าจะเป็นโปรเจ็คที่นำไปศึกษาที่ดีเลยครับ ณ เวลาที่ผมเขียน blog นี้อยู่ source code ของเค้าได้คะแนนเต็ม 4.0 ที่ codeclimate

2 คนนี้เค้าเขียนเจ้า Trailmix นี้ขึ้นมาในกิจกรรม codecation ซึ่ง 2 คนได้ ไปอยู่ในบ้านตามสถานที่พักผ่อนต่างๆ เพื่อเขียน code ร่วมกัน ซึ่ง Ben พูดถึงกิจกรรมนี้ใน keynote ของเค้าที่ Nickel City Ruby Conf ส่วน Chris ได้ทำ github page สำหรับกิจกรรมของเค้าด้วย

เทคนิค filter collection หล่อๆ ของ Clojure ด้วย set

โจทย์คือเราต้องการเลือก element จาก list สำหรับ element ที่มีค่าตรงกับค่าที่ระบุ

เริ่มด้วย Ruby กันก่อน เราอาจจะทำด้วยวิธีต่างๆ ดังนี้

(1..5).select { |e| e == 2 || e == 3 } # => [2, 3]

## ใช้ array เมื่อเริ่มมีหลายตัว
to_take = [2,3,5,7]
(1..10).select { |e| to_take.include?(e) } # => [2, 3, 5, 7]

## ใช้ set เพื่อ performance ที่ดีขึ้น
require 'set'
to_take = Set.new([2,3,5,7])
(1..10).select { |e| to_take.member?(e) } # => [2, 3, 5, 7]

มาดูเทคนิคที่ว่านี้บน Clojure กัน

(filter #{2 3 5 7} [1 2 3 4 5 6 7 8 9 10]) ;=> (2 3 5 7)
; หรือถ้าเรียกใช้ range แทน
(filter #{2 3 5 7} (range 1 11)) ;=> (2 3 5 7)

Continue reading

รีวิวหนังสือ Understanding the Four Rules of Simple Design

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

Understanding the Four Rules of Simple Design

Screen Shot 2014-04-02 at 9.32.55 PM

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

Continue reading