สารคดี Ruby on Rails [วิดีโอ]

 (youtube.com)
1 คะแนน โดย GN⁺ 2023-11-14 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • จุดเริ่มต้นของ Rails เกิดขึ้นระหว่างการพัฒนา Basecamp ของ 37signals เมื่อ David Heinemeier Hansson สร้างเครื่องมือที่จำเป็นขึ้นเองด้วย Ruby
  • การร่วมงานกันของ Jason Fried และ David เริ่มจากคำถามเรื่อง PHP บนบล็อกของ 37signals ในปี 2001 ก่อนนำไปสู่การพัฒนาแบ็กเอนด์ของ Basecamp และการ แยก Rails ออกมา
  • Rails พยายามผสานความรู้สึกของการพัฒนาเว็บที่รวดเร็วแบบ PHP เข้ากับความเคร่งครัดของการออกแบบเชิงวัตถุแบบ Java ภายใน Ruby และรูปทรงหลักของมันก่อตัวขึ้นตั้งแต่ฤดูร้อนปี 2003 จนถึงการเปิดตัว Basecamp ในเดือนกุมภาพันธ์ 2004
  • การแพร่กระจายในช่วงแรกได้แรงหนุนจากผลิตภัณฑ์จริงอย่าง Basecamp, เดโม 15 นาที, การเปรียบเทียบกับ Java, ชื่อเสียงของ 37signals และนำไปสู่การก่อตัวของผู้มีส่วนร่วมยุคแรกอย่าง Jamis Buck, Jeremy Kemper, Tobias Lütke รวมถึง Rails core team
  • หลัง Rails ถูกเผยแพร่เป็น โอเพนซอร์สภายใต้ไลเซนส์ MIT ก็ยังคงยืนตามแนวทางที่ว่าทีมเล็ก ๆ ก็สร้างเว็บแอปพลิเคชันขนาดใหญ่ได้ ผ่านกรณีใช้งานขนาดใหญ่อย่าง Shopify และ GitHub ตลอดจนชุมชนที่ดำเนินต่อเนื่องมา 20 ปี

การพบกันของ 37signals กับ David Heinemeier Hansson

  • ในปี 1999 หรือ 2000 Jason Fried บริหารบริษัทออกแบบเว็บชื่อ 37signals และกำลังทำโปรเจกต์เสริมฐานข้อมูลหนังสือออนไลน์ชื่อ Single File ด้วย PHP
  • เขาเรียน PHP จากหนังสือและทำไปได้ค่อนข้างมาก แต่ก็เจอจุดที่ติดขัด และในยุคที่ยังไม่มีพื้นที่ถามตอบอย่าง StackOverflow เขาจึงขอความช่วยเหลือทางออนไลน์
  • David Heinemeier Hansson ซึ่งอยู่ในวงการเว็บที่โคเปนเฮเกน ประเทศเดนมาร์ก อ่านบล็อก Signal vs. Noise ของ 37signals เป็นประจำ และในปี 2001 ก็ได้ตอบคำถามด้านโปรแกรมมิงของ Jason
  • คำตอบของ David ละเอียดมาก และ Jason รู้สึกได้ว่านี่ไม่ใช่แค่คอมเมนต์ธรรมดา แต่เป็นท่าทีที่ต้องการช่วยจริง ๆ
  • หลังจากนั้น David ได้ดูโค้ดทั้งหมดของ Jason แล้วพูดทำนองว่า “อันนี้ไม่ค่อยดี เริ่มใหม่กันเถอะ” และการร่วมงานของทั้งสองก็เริ่มต้นจากจุดนั้น
  • ทั้งสองทำงานทางไกลกันอยู่พักหนึ่ง ก่อนจะพบกันตัวจริงครั้งแรกใกล้ Hancock building ใน Chicago โดย Jason เล่าว่าเสื้อผ้าสีขาวของ David สะดุดตามาก

Rails ถือกำเนิดระหว่างการสร้าง Basecamp

  • 37signals รู้สึกว่าการจัดการโปรเจกต์ลูกค้าผ่านอีเมลทำให้ติดตามเวอร์ชันไฟล์ งานที่เหลือ และสถานะความพร้อมในการเปิดตัวได้ยาก จึงตัดสินใจสร้าง เครื่องมือจัดการโปรเจกต์ สำหรับใช้ภายในในปี 2003
  • ตอนนั้น David เป็นนักศึกษาคณะธุรกิจในโคเปนเฮเกน จึงทำงานได้เพียงประมาณ 10 ชั่วโมงต่อสัปดาห์ และสำหรับค่าตอบแทนในการพัฒนาแบ็กเอนด์ของ Basecamp เขาต้องการแล็ปท็อป Apple กับอุปกรณ์มากกว่าเงิน
  • David ได้รู้จัก Ruby ผ่านงานเขียนของ Martin Fowler และ Dave Thomas และถูกดึงดูดด้วยการที่โค้ดของภาษานี้จากญี่ปุ่นอ่านได้เหมือน pseudocode
  • งานของ 37signals ก่อน Basecamp ใช้ PHP แต่ David ตัดสินใจสร้างแบ็กเอนด์ของ Basecamp ด้วย Ruby และ Jason ก็เชื่อมั่นในทางเลือกนั้น
  • สิ่งที่ David มองหาใน Rails คือการผสานสองอย่างเข้าด้วยกัน
    • ความฉับไว ที่ทำให้ขึ้นเว็บได้รวดเร็วเหมือน PHP
    • ความเคร่งครัดทางปัญญา ของการออกแบบเชิงวัตถุและแพตเทิร์นที่เห็นใน Java
  • ขณะนั้น Ruby ยังมีไลบรารีหรือเฟรมเวิร์กสำหรับช่วยพัฒนาเว็บและเข้าถึงฐานข้อมูลไม่มากนัก David จึงสร้างเครื่องมือที่จำเป็นสำหรับการทำ Basecamp ขึ้นเอง
  • ตั้งแต่ฤดูร้อนปี 2003 จนถึงการเปิดตัว Basecamp ในเดือนกุมภาพันธ์ 2004 แกนหลักของ Rails ได้ก่อตัวขึ้น และหลังเปิดตัว Basecamp เขาใช้เวลาประมาณ 6 เดือนปรับโค้ดกับเอกสารให้เรียบร้อย ก่อนเปิดเผย Rails ในปี 2004

การเปิดตัวช่วงแรก การตลาดที่ก่อประเด็น และการก่อตั้งทีมคอร์

  • ระหว่างเตรียมเปิดเผย Rails David ให้ความสำคัญไม่เพียงกับโค้ด แต่รวมถึง คุณภาพของเอกสาร ด้วย และเห็นว่าเวอร์ชันแรกต้องดีพอ
  • เมื่อ Rails เริ่มได้รับความสนใจ David พยายามปกป้องทิศทางของเฟรมเวิร์กอย่างแข็งขัน และพูดว่า “ไม่” ต่อข้อเรียกร้องที่เขาไม่ต้องการ
  • ในงาน Rails conference ยุคแรก David ใช้สไลด์ที่เขียนว่า “F()c% You” เพื่อตอบโต้ข้อเรียกร้องที่ไม่สมเหตุสมผลและการขู่เรื่องความล้มเหลว พร้อมแสดงจุดยืนว่าโอเพนซอร์สไม่ใช่ความสัมพันธ์เชิงพาณิชย์ และผู้ใช้ไม่สามารถสั่งทิศทางได้
  • ในขณะเดียวกัน Rails ก็เติบโตด้วยการรับผลงานดี ๆ จากผู้มีส่วนร่วมหลายพันคน และไม่ได้หมายความว่า David ปฏิเสธฟีดแบ็กหรือการมีส่วนร่วมในตัวมันเอง
  • ในงาน International Ruby Conference ปี 2004 David แนะนำ Rails โดยเน้นเหตุผลที่สร้าง Rails และเป้าหมายในการมอบประสบการณ์ที่ดีกว่าให้โปรแกรมเมอร์ มากกว่าการสาธิตโค้ด
  • ในช่วงประมาณ 1 ปีแรก มีเพียง David ที่ commit โค้ดโดยตรง ส่วนแพตช์รับผ่านอีเมลและ Wiki เป็นต้น
  • ต่อมาเขาให้สิทธิ์เข้าถึง codebase แก่ผู้ที่มีส่วนร่วมจำนวนมาก และ Rails core team ก็ถูกสร้างขึ้น โดยมี Jamis Buck, Jeremy Kemper, Marcel Molina, Scott Barron, Sam Stephenson, Michael Koziarski และคนอื่น ๆ เข้าร่วมเป็น committer รุ่นแรก
  • 37signals จ้างบางคนจาก Rails core team หรือผู้มีส่วนร่วมของ Rails เข้าบริษัท และ Jamis Buck ก็กลายเป็นโปรแกรมเมอร์คนแรกที่ 37signals จ้างในช่วงที่ Basecamp กำลังเติบโต

การแพร่กระจายที่เกิดจากผลิตภัณฑ์จริงและระบบนิเวศ

  • ความสนใจช่วงแรกที่ Rails ได้รับมีชื่อเสียงของ 37signals และผลิตภัณฑ์ที่ประสบความสำเร็จจริงอย่าง Basecamp เป็นปัจจัยสำคัญ
  • David มองว่าหากต้องการทำให้เครื่องมือที่อิงกับภาษาที่คนยังรู้จักน้อยกว่าอย่าง Ruby เป็นที่รู้จัก การแนะนำแบบเงียบ ๆ ไม่พอ ต้องส่งเสียงให้ดัง และเขาก็สร้างเอกสารเชิงถกเถียงที่เปรียบเทียบการทำงานแบบ Java กับแบบ Rails
  • การแพร่กระจายของ Rails เกิดจาก เดโม 15 นาที, ลูกค้าแบบชำระเงินและการเติบโตของ Basecamp รวมถึงโค้ดที่ใช้งานได้จริงประกอบกัน
  • Tobias Lütke ใช้ Rails ตั้งแต่ช่วงแรกมาก ๆ ขณะสร้างร้านสโนว์บอร์ดออนไลน์ในช่วงที่กำลังเริ่มบริษัทในแคนาดา และโปรเจกต์นั้นที่ชื่อ Snowdevol ต่อมาก็เชื่อมโยงไปสู่ Shopify
  • Tobias เล่าว่าด้วย Rails เขาสามารถสร้างระบบได้ด้วยตัวคนเดียว และในเวลานั้นเขามี productivity สูงกว่าทีมอื่น ๆ ที่สร้างร้านค้าออนไลน์
  • Shopify เป็นบริษัทที่ได้รับอิทธิพลจาก Rails และปัจจุบันก็ยังใช้ Rails เวอร์ชันล่าสุด โดย codebase ส่วนใหญ่เป็น Ruby และโครงสร้างโฟลเดอร์พื้นฐานก็เหมือนแอป Rails ทั่วไป
  • คำวิจารณ์ว่า Rails “สเกลไม่ได้” มีมาตั้งแต่ช่วงแรก แต่ Basecamp ก็รองรับผู้ใช้จริง และก่อนจะมีกรณีอย่าง Shopify หรือ GitHub ก็มีการโต้แย้งต่อเนื่องว่า Rails สเกลได้ตั้งแต่แรก
  • Shopify ถูกพูดถึงในฐานะบริการขนาดใหญ่ที่ครองประมาณ 10% ของอีคอมเมิร์ซทั่วโลก และก็มีประสบการณ์เล่าว่าไม่รู้เหมือนกันว่าขนาดแบบไหนกันที่ Rails จะรับไม่ไหว

รีลีส การรวมกับ Merb และทิศทางที่ดำเนินมา 20 ปี

  • การเปิดเผย Rails เป็นโอเพนซอร์สตั้งแต่แรกเป็นทางเลือกที่ชัดเจนอยู่แล้ว และ David มองว่าเพราะรากฐานที่ทำให้งานเว็บของเขาเป็นไปได้คือเครื่องมือโอเพนซอร์ส เขาก็ควรแบ่งปันกล่องเครื่องมือของตัวเองด้วย
  • แม้จะมีการพูดคุยเรื่องทำ Rails เป็นผลิตภัณฑ์เสียเงินหรือเก็บไว้เป็นความได้เปรียบในการแข่งขัน แต่ David ตัดสินใจว่า โอเพนซอร์สภายใต้ไลเซนส์ MIT เป็นสิ่งสำคัญ และจะทำให้ Rails ประสบความสำเร็จอย่างมาก
  • เครื่องมือที่ Jamis Buck สร้างขึ้นเพื่อ deploy Basecamp ต่อมากลายเป็นที่รู้จักในชื่อ Capistrano
  • ลำดับรีลีสหลักของ Rails มีดังนี้
    • Rails 1.0 เป็นจุดเริ่มต้นสำคัญ
    • Rails 1.2 ถูกประเมินว่าเป็นรีลีสยุคแรกที่เสถียร และเป็นช่วงที่แสดงรูปลักษณ์ของเว็บเฟรมเวิร์กที่เติบโตเต็มที่
    • Rails 2.0 ในเดือนธันวาคม 2007 นำ session แบบอิงคุกกี้และ named scopes เป็นต้นเข้ามา
    • Rails 2.3 ในเดือนมีนาคม 2009 ถูกพูดถึงว่าเป็นรีลีสที่มีเครื่องมือที่นักพัฒนาเว็บยุคใหม่ต้องการครบ ตั้งแต่แอปขนาดเล็กไปจนถึงขนาดใหญ่
  • ในช่วง Rails 2.3 jQuery กำลังปรากฏขึ้น และ Rails พยายามสร้างพื้นที่เพื่อรับพลังจากโลก JavaScript
  • ต่อมาเว็บเฟรมเวิร์ก Ruby อย่าง Merb ปรากฏขึ้นในฐานะคู่แข่งที่เร็วกว่า เบากว่า และทำสิ่งต่าง ๆ น้อยกว่า และนักพัฒนา Rails ก็มองเห็นสิ่งที่ควรเรียนรู้จากทิศทางนั้น
  • Rails 3.0 นำไปสู่การรวมกับ Merb ซึ่งต้องอาศัยงานใหญ่ในการออกแบบภายใน Rails ใหม่ให้เป็นโครงสร้างที่กำหนดค่าได้ ประกอบใหม่ได้ และเป็นโมดูลาร์
  • ชุมชน Rails มุ่งเน้นให้แม้แต่คนที่ไม่ได้เรียนวิทยาการคอมพิวเตอร์หรือการเขียนโปรแกรมอย่างเป็นทางการ ก็สามารถสร้างเว็บแอปพลิเคชันและสร้างอาชีพได้
  • Rails พยายามลดกำแพงในการเริ่มต้น และมอบเส้นทางให้เติบโตเป็นโปรแกรมเมอร์ระดับสูงในบริษัทหรืออุตสาหกรรมต่อไป
  • ตามข้อความบนเว็บไซต์ Rails ในปัจจุบัน Rails คือเฟรมเวิร์กที่ช่วยให้ทีมเล็ก ๆ ไปได้ตั้งแต่ “Hello World ถึง IPO” และถูกประเมินว่าคุณภาพของชุมชนและ codebase ในตอนนี้ดีที่สุดแล้ว

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2023-11-14
ความคิดเห็นจาก Hacker News

  • ดูสารคดีนี้แล้วสนุกมาก และมุมมองเรื่อง เฟรมเวิร์กที่ขับเคลื่อนโดยคนคนเดียว ก็ถ่ายทอดออกมาได้ชัดผ่านเรื่องราวส่วนตัวของ Toby จาก Shopify
    “From Hello World to IPO” ก็ดีมาก และสิ่งที่น่าประทับใจเป็นพิเศษคือคำพูดที่ว่า ไม่ว่าจะเปิดดูแอป Rails ไหน ไม่ว่าจะเป็นแอป Rails ที่ใหญ่ที่สุดหรือแอปใหม่ โครงสร้างก็แทบจะเหมือนกันหมด
    ในสภาพแวดล้อมปัจจุบันที่ API กับสแตกฝั่งฟรอนต์เอนด์พันกันไปหมด ความสม่ำเสมอแบบนี้ไม่ได้การันตีเสมอไป
    การเปลี่ยนแปลงล่าสุดของ Rails กำลังทำให้รากฐานที่แข็งแรงยิ่งแน่นขึ้นไปอีก และไม่ใช่แค่ Kamal เท่านั้น แต่ยังมีงานอย่าง Solid Cache และ Solid Queue ที่ช่วยทำให้อินฟราง่ายขึ้นด้วย
    ฝั่งฟรอนต์เอนด์ก็มี Turbo Morphing ส่วนแอปมือถือก็มี Turbo Native และ Strada ที่ยังเดินหน้ากันอย่างคึกคัก
    อัปเกรดเป็น 7.1 ไปแล้ว และตอนนี้ก็รันแอปมือถือที่ทำด้วย Turbo Native อยู่ จึงตั้งตารอที่จะเปลี่ยน Redis cache ไปเป็น Solid Cache เพื่อให้ระบบง่ายขึ้นและแคชนานขึ้น
    ชอบที่ชุมชน Rails ยังมีชีวิตชีวา และสมาชิกคอร์ทีมทั้งอดีตและปัจจุบันก็ยังเชื่อมโยงกับเฟรมเวิร์กอย่างลึกซึ้ง

    • ประโยคที่ว่า “ไม่ว่าจะเปิดดูแอป Rails ไหน ไม่ว่าจะเป็นแอปใหญ่ที่สุดหรือแอปใหม่ โครงสร้างก็แทบจะเหมือนกัน” ฟังดูยอดเยี่ยมจริง ๆ
      ไม่เคยใช้ Rails มาก่อน แต่สิ่งที่เกลียดมากใน ecosystem ของ Node.js คือการ ไม่มีธรรมเนียมปฏิบัติที่ชัดเจน
      ต่อให้ใช้เฟรมเวิร์กเดียวกัน โครงสร้างก็ต่างกันตลอดจนเละเทะ ข้อยกเว้นคงมีแค่ Next.js แต่ถึงอย่างนั้นมันก็ใกล้กับฝั่งฟรอนต์เอนด์มากกว่า
    • YJIT ใน Ruby 3.3 เร็วกว่า Ruby 2.5 ถึง 2 เท่าบน RailsBench และก็มีการย้าย Ruby Gem ที่เขียนด้วย C มาเป็น Ruby ด้วย ซึ่งอาจทำให้ JIT ทำงานได้ง่ายขึ้น
      เครื่องมือพัฒนารอบ ๆ Ruby และ Rails ก็ออกมาเยอะมาก เลยหวังว่า Rails 8.0 กับ Ruby 3.4 จะมีการเปลี่ยนแปลงดี ๆ เพิ่มอีก
    • ทำ Rails มา 15 ปี แถมยังเขียนหนังสือด้วย แต่ก็รู้จัก Tobi แค่ว่าเป็นคนที่ทำงานด้าน Rails ที่ดัง ๆ ไว้หลายอย่าง
      มารู้ทีหลังว่าเป็นผู้ก่อตั้ง Shopify และมีทรัพย์สิน 5.5 พันล้านดอลลาร์ ก็ขำดี
    • เห็นด้วยเต็มที่ว่าโครงสร้างแอป Rails แทบจะเหมือนกันไม่ว่าขนาดจะใหญ่แค่ไหน
      นักพัฒนามักประเมินคุณค่าของแง่มุมนี้ใน RoR ต่ำเกินไปจริง ๆ
      มันไม่เพียงทำให้ onboarding ง่ายขึ้น แต่ยังลด bikeshedding ลงได้มากด้วย
      MVC อาจไม่ใช่สิ่งที่ดีที่สุดสำหรับทุกอย่าง แต่สำหรับกรณีส่วนใหญ่ก็ถือว่าดีพอมาก
    • โครงสร้างของ Rails คือประสบการณ์แรกของผมกับการพัฒนาเว็บในฐานะอาชีพ และหลังจากนั้นมันก็ทำให้มาตรฐานที่ผมใช้มองอย่างอื่นพังไปหมด

  • ไว้วันนี้เดี๋ยวต้องกลับมาดูอันนี้
    เคยลองเฟรมเวิร์กมาหลายตัวทั้ง Laravel, ExpressJS, MeteorJS, Django, Flask แต่ละตัวก็มีข้อดีข้อเสียของตัวเอง แต่สุดท้ายพอทำตามทิวทอเรียลหรือพยายามทำในแบบของตัวเองก็มักจะเลิกกลางทางทุกที
    เพิ่งเริ่มใช้ Rails เมื่อสามวันก่อน แต่ก็สามารถทำ MVP ขึ้นมาอย่างรวดเร็วในช่วงสุดสัปดาห์เพื่อเอาไปให้เพื่อนร่วมงานดูได้
    Rails ทำให้โฟกัสกับสิ่งที่แอปควรทำ แทนที่จะหมกมุ่นกับวิธีลงมือสร้างมัน และตอนนี้ก็เพิ่งเข้าใจว่าทำไมคนถึงชอบกันมาก

    • ทำงานเป็นนักพัฒนา Rails มานาน และลองอย่างอื่นมาหลายแบบ แต่สุดท้ายก็มักกลับมาที่ Rails ด้วยเหตุผลเดิม
      บน Rails ผลิตภาพสูงมากจริง ๆ
      ข้อบ่นใหญ่ที่สุดมาแต่ไหนแต่ไรคือ ถ้าออกนอกธรรมเนียมที่วางไว้แล้ว เอกสารจะไม่พอหรือมีข้อมูลที่ขัดกันเยอะมาก
      การหาว่า “วิธีที่ได้รับการยอมรับ” คืออะไรและทำความเข้าใจมันอาจยากมาก แต่โชคดีที่ ChatGPT ค่อนข้างช่วยตั้งต้นในเรื่องแบบนี้ได้ดี

  • เป็นสารคดีที่ยอดเยี่ยมจริง ๆ
    ใช้ Rails มาหลายปีแล้ว และมันมีผลิตภาพสูงมากสำหรับทีมเล็กที่สร้างผลิตภัณฑ์และทำ business logic ตามแพตเทิร์นที่วางไว้อย่างชัดเจน
    ถ้าอยากรู้ว่าโครงสร้างแอป Rails จริง ๆ เป็นอย่างไร แนะนำให้ดูโค้ดเบสของ Jumpstart เป็นแหล่งเรียนรู้ที่ดีมากเรื่องการวางโครงสร้าง
    https://jumpstartrails.com/
    อีกทางเลือกหนึ่งคือ Bullet Train ซึ่งก็ดีพอตัว แต่เพิ่มไลบรารีเฉพาะทางจำนวนมากจนเรียกได้ไม่เต็มปากว่าเป็น “แนวทางแบบ Rails”
    https://bullettrain.co/

  • คิดว่าสารคดี Rails กับสารคดี Elixir ยังเล่าอะไรได้ไม่มากพอ
    มันสั้นเกินไป เลยเพิ่งเกริ่นเรื่องจุดกำเนิดได้ไม่นานก็จบแล้ว และจบก่อนจะไปถึงจุดที่ชวนตื่นเต้นจริง ๆ
    แทนที่จะทำให้คนในและนอกชุมชนเห็นว่าเทคโนโลยีเหล่านี้เจ๋งแค่ไหน มันกลับดูใกล้เคียงกับการช่วยเสริมอัตตาให้ผู้ให้สัมภาษณ์มากกว่า
    อยากให้มี สารคดีความยาว 1 ชั่วโมง 30 นาที สำหรับทั้ง Elixir และ Rails โดยก้าวข้ามช่วงที่ทุกคนชมกันเอง แล้วพาไปดูทั้งความลำบากตลอดหลายปี วิธีการใช้งานที่หลากหลายในหลายบริษัท ฯลฯ
    พูดอีกแบบคือ ถ้าเอารูปแบบของ Indie Game: The Movie มาใช้ก็น่าจะดึงดูดกว่านี้มาก และก็อยากเห็นสารคดีเกี่ยวกับซอฟต์แวร์ดี ๆ ออกมาอีกเยอะ

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

  • ดูแล้ว แต่คิดว่ามันยังแสดงให้เห็นไม่พอว่า Rails ทำอะไรสำเร็จไว้บ้าง
    Ruby on Rails เปลี่ยนกระบวนทัศน์ของการสร้างเว็บแอปจากแนวทางแบบยึดไฟล์เป็นศูนย์กลางอย่าง PHP, JSP, WebForms ไปสู่การใช้ route และแพตเทิร์น MVC และทุกวันนี้ถ้าเป็นเว็บเฟรมเวิร์กที่ดีจริงก็มักมีแนวทางนี้กันแทบทั้งหมด
    สารคดีไม่ได้พูดถึงจุดนั้น แต่ถึงอย่างไรก็ดูเพลินดี

    • Struts เป็น Java MVC framework ที่ได้รับความนิยมในช่วงต้นทศวรรษ 2000 และออกมาก่อน Rails
      แต่ก็ยังรู้สึกเกรงใจนิด ๆ ถ้าจะเอา Struts กับ Rails มาอยู่ในประโยคเดียวกัน เพราะ Rails ทำสำเร็จไว้มากกว่ามาก
    • MVC ถูกใช้มาก่อน Ruby on Rails นานแล้วในเฟรมเวิร์กอย่าง WebObjects

  • บุคคลระดับตำนานในยุคแรกของ Rails เป็นคนปูทางให้กับวิธีสร้างเว็บแอปสมัยใหม่
    ถึงขั้นพูดได้เลยว่า ในโลกเว็บดีเวลลอปเมนต์มี ยุคก่อน Rails และหลัง Rails

  • อ่านคอมเมนต์แล้วรู้สึกว่า Rails กำลังกลับมาได้รับความนิยมขึ้นอีกนิด จากเดิมที่ถูกมองว่าเป็นแค่เฟรมเวิร์กที่น่าเบื่อแต่แข็งแรง

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

  • สิ่งที่ชื่นชมมากใน Rails คือ วิสัยทัศน์ที่ชัดเจน และมันไม่กลายเป็นอีกหนึ่งเฟรมเวิร์กอุ้ยอ้ายสำหรับสร้างแอปพลิเคชัน “ระดับเอ็นเตอร์ไพรส์”
    แม้จะเป็นเฟรมเวิร์กอายุ 20 ปีแล้ว แต่มันก็ไม่กลัวที่จะเปลี่ยนแปลงอย่างกล้าหาญให้ทันยุคสมัย และยังดูพังก์กว่าอย่างอื่นอยู่ดีเมื่อเทียบกัน
    พอนึกถึงเรื่องของตัวเองตอนเริ่มใช้ Rails เมื่อ 20 ปีก่อนก็รู้สึกอบอุ่นใจ
    https://twitter.com/buger/status/1723040883325460818

  • ตั้งแต่ปี 2015 ถึง 2019 เคยทำงานกับ Rails app ขนาดใหญ่มากที่ใช้งานจริง และผลก็คือรัก Rails แต่เกลียด Ruby
    ถ้ามี Rails ที่เป็น TypeScript หรือ Go ผมแทบนึกเหตุผลไม่ออกเลยว่าจะใช้ตัวอื่นเป็นแบ็กเอนด์ของเว็บแอปไปทำไม
    Rails Console เป็นหนึ่งในเครื่องมือเพิ่มผลิตภาพที่ดีที่สุดเท่าที่เคยใช้มา

    • อยากเห็น Go REPL ที่ทำอะไรได้เยอะพอ ๆ กับ Ruby REPL แต่ในโลกจริงมันดูแทบเป็นไปไม่ได้
      TypeScript อาจพอทำได้ถ้าใช้ Node REPL ที่มีอยู่เดิม แต่เหตุผลใหญ่ที่ Rails console มีประโยชน์ขนาดนั้น สุดท้ายก็มาจากตัว Ruby เอง

  • สารคดีของ Honeypot ดีมากจริง ๆ แนะนำอย่างยิ่ง