Rails สำหรับทุกอย่าง - ความแข็งแกร่งของ Rails สำหรับทุกอย่าง

 (literallythevoid.com)
7 คะแนน โดย GN⁺ 2025-01-03 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • Rails 8 มีความมีประโยชน์มากสำหรับโครงการขนาดเล็กและนักพัฒนาเดี่ยว
  • สามารถสร้าง แอประดับ production ได้อย่างง่ายดายด้วยคู่มือเริ่มต้นล่าสุด
  • ด้วยการปรับปรุงของ SQLite ทำให้สร้างสภาพแวดล้อมฐานข้อมูลที่ทรงพลังได้โดยไม่ต้องใช้เซิร์ฟเวอร์เพิ่ม
  • ตัวสร้าง การบูรณาการต่อเนื่อง (CI) และการยืนยันตัวตน ในตัวช่วยยกระดับประสิทธิภาพการพัฒนาและความปลอดภัย
  • การ deploy แบบง่ายผ่าน Kamal ช่วยให้ให้บริการของคุณใช้งานได้อย่างรวดเร็วและปลอดภัย

ภาพรวม

  • โดยอาศัยประสบการณ์การใช้งาน Rails 8 มันเป็น เว็บเฟรมเวิร์กที่ยอดเยี่ยม สำหรับโครงการขนาดเล็กหรือนักพัฒนาเดี่ยว
  • ความสามารถด้านการพัฒนาที่เร็วขึ้น การ deploy อย่างมีประสิทธิภาพ และโมดูลในตัว ทำให้เห็นข้อได้เปรียบด้าน productivity เมื่อเทียบกับเฟรมเวิร์กคู่แข่งชัดเจน

จุดเด่นของคู่มือเริ่มต้นใหม่

  • คู่มือ Getting Started with Rails เวอร์ชันล่าสุดจัดทำให้ผู้เริ่มต้นสามารถสร้าง แอประดับ production ได้
  • แม้ว่าขั้นตอนการติดตั้ง Ruby จะยังค่อนข้างซับซ้อนอยู่บ้าง แต่ถ้าทำตามคำแนะนำในคู่มือก็สามารถสร้างบริการที่แข็งแรงได้ด้วย การยืนยันตัวตน, caching, rich text, การบูรณาการต่อเนื่อง และฐานข้อมูล
  • ข้อเด่นไม่ใช่แค่แอป “Hello World” แต่คือการมอบพื้นฐานและฟังก์ชันที่เหมาะสมกับระดับบริการจริง
  • เป็นจุดเริ่มต้นที่เหมาะสมที่สุดสำหรับผู้เริ่มต้นที่ยังไม่คุ้นเคยกับ Rails

SQLite ตัวเดียวก็เพียงพอ

  • โดยพื้นฐานแล้ว SQLite เป็นเครื่องมือที่ยอดเยี่ยม แต่ก่อนหน้านี้การใช้งานในเชิง production เคยทำได้ยากเมื่อปรับค่าใช้งานจริง
  • เดิมต้องทำงานเพิ่มเติม เช่น ติดตั้ง gem เพิ่มเติม แต่ใน Rails 8 สามารถใช้งานได้อย่างเสถียรในสภาพแวดล้อม production โดยไม่ต้องเพิ่มขั้นตอนใด ๆ
  • ไม่จำเป็นต้องรัน PostgreSQL หรือเปิดใช้งานเซิร์ฟเวอร์แยก และหากใช้ solid cache ก็ไม่จำเป็นต้องมีเซิร์ฟเวอร์ redis
  • การรันบริการด้วยเพียง Rails และ SQLite เท่านั้น ทำให้การสร้างและการดูแลระบบเรียบง่าย และช่วยเพิ่มความคุ้มค่าเชิงต้นทุนสูงสุด

การบูรณาการต่อเนื่อง (CI) ที่ใช้งานง่าย

  • หลังจาก commit แรก ระบบจะส่งการแจ้งเตือนความล้มเหลวของ CI ได้แล้ว ซึ่งแสดงว่า Rails 8 มีการตั้งค่า CI ที่ผสานไว้ล่วงหน้า
  • เชื่อมต่อกับ GitHub Actions ได้โดยไม่ต้องทำงานเพิ่มเติม และสามารถรับเวลาใช้งานฟรีได้เดือนละ 2,000 นาที
  • สำหรับนักพัฒนาเดี่ยว มันถือว่าเป็นเวลาที่ค่อนข้างสบายตัวมาก

การนำตัวสร้างการยืนยันตัวตนมาใช้

  • Gem ของการยืนยันตัวตนแบบ Devise ที่มีอยู่เดิมแม้จะทรงพลัง แต่ความซับซ้อนในการตั้งค่าทำให้ผู้เริ่มต้นรู้สึกยากได้
  • ใน Rails 8 มีการเพิ่ม ตัวสร้างการยืนยันตัวตนแบบง่าย ทำให้สามารถเพิ่มเฉพาะผู้ใช้เดิมผ่านคอนโซลและสร้าง login flow ได้ง่าย
  • โค้ดที่ถูกสร้างมีความง่ายและอ่านง่าย ทำให้ผู้เริ่มต้นเข้าใจได้โดยไม่ลำบาก

การ deploy ที่ง่ายและรวดเร็วด้วย Kamal

  • กระบวนการ deploy ถูกดูแลโดย Kamal โดยคุณเพียงแก้ไขบางส่วนของไฟล์ deploy.yml และทำตามคำแนะนำ ก็สามารถเปิดใช้แอปในสภาพแวดล้อม SSL ได้ทันที
  • การ deploy เว็บแอปนี้เกิดขึ้นได้รวดเร็วกว่าเชื่อม SSL กับ GitHub Pages
  • การผสมผสานของ CI ที่รวมมาแล้ว และการ deploy ที่ง่ายเป็นอีกจุดเด่นที่เด่นชัดของ Rails 8
  • เพียงทำตามคู่มือเริ่มต้น คุณก็สามารถมีประสบการณ์การพัฒนาที่สอดคล้องกับแนวปฏิบัติที่ดีที่สุดล่าสุดได้

บทสรุป

  • Rails ยังคงเป็นเฟรมเวิร์กที่ทรงพลัง และยังคงพัฒนาอยู่
  • หากคุณกำลังพิจารณาโครงการใหม่ในปีนี้ การลองพัฒนา ด้วย Rails 8 ย่อมมีคุณค่า

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

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

 
aer0700 2025-01-06

ช่วงนี้เห็นบทความเกี่ยวกับ SQLite กันเยอะมาก จนตอนนี้มาอยู่ในขั้นที่ ทุกอย่าง ก็เป็น SQLite แล้วนะ ควรเรียกว่านี่คือการฟื้นคืนความนิยมแบบคลาสสิกกันหรือเปล่านะ?
 
GN⁺ 2025-01-03
ความคิดเห็นจาก Hacker News
  • ช่วงนี้ผมทำแอปด้วยสแตก Spring Boot และ Micronaut และลองใช้ React ฝั่ง frontend ด้วย จึงรู้สึกว่าระบบ omakase (ทุกอย่างพร้อมใช้งาน) ของ Rails ช่วยได้มากทีเดียว ก่อนหน้านี้แม้เป็นฟีเจอร์พื้นฐานจาก backend อย่าง การตรวจสอบความถูกต้องของฟอร์ม หรือข้อความ flash ก็ยังต้อง implement เองหรือหา third-party มาช่วย เพราะ framework ไม่ได้จัดการให้โดยตรง Rails แก้ปัญหาที่เว็บแอปเจอบ่อยถึง 90% ไว้ให้ล่วงหน้าได้ แม้จะไม่สามารถพูดได้ว่าเพอร์เฟ็กต์ในทุกด้าน แต่ในกรณีส่วนใหญ่สิ่งที่มีมาให้ก็เพียงพอ และหากจำเป็นก็สามารถแทนที่ได้ตลอดเวลา
    • Spring Boot มี การตรวจสอบความถูกต้องของฟอร์ม มาใกล้ครบในตัว และทำได้ทันทีด้วย annotation
  • ผมมองว่า Rails และ Django ต่างก็เป็น เฟรมเวิร์กที่เยี่ยมมาก ผมเคยทำแอปที่มีความสำคัญสูงด้วย Python มาก่อนเช่นกัน แต่สำหรับการพัฒนา monolith ขนาดใหญ่ ผมมีแนวโน้มจะย้ายไปใช้ Go เพราะรู้สึกว่าระบบชนิดและ concurrency ของ Go แรงกว่า อย่างไรก็ดี ปัญหาคือฝั่ง Go ไม่ได้สร้าง ecosystem เฟรมเวิร์กแบบ Rails หรือ Django ให้เราได้ Go เหมาะมากสำหรับงาน เครื่องมือ networking หรือ CLI แต่เมื่อทำเว็บแอป full-stack แบบเร็วๆ ยังเลือก Rails หรือ Django อยู่เลย เพราะงั้นประโยคว่า “Rails ตายแล้ว” ยังไม่รู้สึกว่ามีความหมายมาก
    • ด้วยเครื่องมืออย่าง ogen จากเอกสาร OpenAPI เพียงชิ้นเดียว เราสามารถ generate ออกมาได้เกือบทุกอย่าง เช่น static router, การตรวจสอบ request/response, Prometheus monitoring, OpenTelemetry tracing และอื่นๆ โดยอัตโนมัติ สามารถ generate โค้ด webhook ฝั่ง client ได้ด้วย การทำ authentication ก็แค่เพิ่มฟีเจอร์หนึ่งอย่างเท่านั้น โดยผสมผสาน sqlc กับ pragma user_version ของ SQLite จะทำให้การสร้างโค้ด DB แบบ type-safe และ migration ง่ายขึ้น การเพิ่ม SQLite ก็แค่ import สองบรรทัดใน main.go เท่านั้น ส่วนเทมเพลตมาตรฐานของ Go อย่างเดียวก็จัดการเทมเพลตข้อความฝั่ง frontend ได้พอสมควร และใช้ embed ใส่ static asset เข้า binary ได้ง่ายมาก การ deploy เองก็แค่ go build แล้วย้าย binary เท่านั้น การ generate โค้ดช่วยให้การพัฒนา backend ด้วย Go เร็วและสะดวกมากขึ้น
    • ผมเองก็อยากได้สแต็กที่ static type ครบถ้วน แต่ชัดเจนว่า ASP.NET เหมาะสมกว่า Go หรือ Rust มากกว่า ในขณะที่ Microsoft โปรโมตผลิตภัณฑ์ใหม่ๆ (เช่น Aspire.NET) หนักมาก แต่ผลที่เห็นคือ .NET Core (C#, ASP.NET Minimal API/MVC, EF Core) กลับเป็นตัวที่เหมือนมีแบตเตอรี่นำติดตัวและเชื่อถือได้สูงมาก แม้ต้องเปลี่ยน mindset ระหว่าง OOP และ DI เล็กน้อย แต่สำหรับนักพัฒนาที่มีประสบการณ์แล้วไม่ใช่ปัญหาใหญ่
    • ปัญหาของ ecosystem Go ไม่ได้มีแค่ แนวคิดต่อต้านเฟรมเวิร์ก เท่านั้น แต่ยังมี แนวคิดต่อต้านฟีเจอร์สมัยใหม่ ด้วย Java, Kotlin, Scala, C#, F# และอื่นๆ ก็เยี่ยมมากสำหรับงานสร้างเครื่องมือเครือข่ายหรือ CLI ช่วงนี้ Java AOT ก็ไม่ต้องห่วงเรื่อง license เชิงพาณิชย์ และ .NET ก็ไม่ติดอยู่กับ Windows อีกต่อไป
    • ผมอยากแนะนำ Encore โดยเฉพาะเมื่อเชื่อมกับ PaaS (เหมือนชุด NextJS+Vercel) มันทรงพลังมาก แม้อาจต่างจากหลักการหลักของ Go อยู่บ้าง แต่สำหรับ ทีมเล็กหรือทีม 1 คน เป็นตัวเลือกที่ดีมาก ถ้าต้องการก็ deploy เองด้วย BYOC หรือทำ API layer เองด้วย stdlib ก็ไม่มีปัญหา Frontend ยังคงต้องใช้ NextJS หรือ Remix/RR7 อยู่ แต่ด้วยการ generate TypeScript client SDK อัตโนมัติ การผสานทำได้ง่ายมาก อีกจุดแข็งหนึ่งคือ Encore เชื่อมกับ Vercel PR ด้วย
    • หากต้องการความรู้สึกแบบ Django บน Go ตัวเลือกที่ค่อนข้างดีคือ beego แต่ยังรู้สึกว่า ความสมบูรณ์ มันยังไม่ถึงระดับที่เปรียบเทียบเท่า Django หรือ Rails
    • ตอนนี้ผมมีโปรเจกต์ Go อยู่ และรู้สึกพึงพอใจกับโค้ดที่ค่อนข้างสะอาดมาก AI ช่วยให้ข้ามอุปสรรคในการเข้าโลก framework ได้เยอะ อย่างไรก็ตามผมเชื่อว่า บริการแบบเน้นลูกค้า ควรเป็น Rails และงาน internal tool/งานข้อมูลน่าจะ intuitive กว่าในฝั่ง django
    • Ruby ใช้ Sorbet ก็สามารถทำ type checking ได้ และฟีเจอร์ concurrency ที่รองรับด้วย Fiber มีความสมบูรณ์ใกล้ครบแล้ว Falcon web server ใหม่กำลังก่อสร้างด้วย Fiber แม้ยังไม่ถึงระดับ Puma แต่เร็วๆ นี้น่าจะพร้อมใช้งานเต็มตัว
    • ผู้เขียนภาษาของ Stanza เคยเขียนความคิดว่าถ้าต้องการเฟรมเวิร์กที่ทรงพลัง (แบบ Rails) ต้องมีเงื่อนไขในตัวภาษาด้วย ผมจึงเห็นว่าความไม่พบเฟรมเวิร์กระดับนั้นใน Go หรือ Java น่าจะเป็นผลรวมของข้อจำกัดของภาษา (หรือข้อจำกัดของนักพัฒนา) เลย
    • Go ดั้งเดิมไม่เคยเน้นแนวทางเฟรมเวิร์ก full-stack แบบ (Rails/Django)
    • Node/Express เหมาะกับระดับ pico service สำหรับการพัฒนาท้องถิ่นมากกว่า และสำหรับผมแล้ว ASP.NET WebAPI/MVC คือ backend ที่เป็นอุดมคติ
    • goravel dev ก็ลองสักครั้งก็น่าจะคุ้ม
  • ถ้าทำตาม Rails Guides ตั้งแต่ต้นจนจบ คุณจะปล่อย บริการจริง ที่มี auth, caching, rich text, CI, DB ครบได้เลย แต่แม้เหมาะกับบริการยักษ์ใหญ่แบบ GitHub, Airbnb ก็ตาม ใน startup ระยะแรก การใส่ฟีเจอร์เสริม/ในตัวทั้งหมดตั้งแต่แรกอย่าง Devise auth, turbo, test อาจกลายเป็นการเสียเวลาแทนได้ Turb โดนประหยัดเวลาบ้างเพราะหน้าโหลดเร็วขึ้น แต่กลับชนกับฟังก์ชันของ devise ทำให้ระยะเวลาพัฒนาเพิ่มได้ด้วย เมื่อยังเป็นช่วงคิดทฤษฎีก่อนเปิดตัวอย่างจริงจัง โดยเฉพาะไม่ใช่แอปธนาคาร/การแพทย์ ก็ย่อมหยุดทิ้ง test หรือ CI ได้ก่อนชั่วคราว โดยไม่เกิดปัญหาใหญ่ ข้อสำคัญคืออย่าเชื่อ default bias (เพราะมีอยู่จึงใช้) และกล้าพูดตรงๆ ว่า “ตอนนี้ไม่ใช้” กับสิ่งที่ไม่ต้องการ
    • ถ้าคิดทำ SaaS app การเริ่มด้วยเทมเพลต Rails เฉพาะทางอย่าง Jumpstart Pro หรือ Bullet Train จะช่วยลดเวลาพัฒนาหลายเดือน เพราะมีฟีเจอร์พื้นฐานอย่าง payment, auth มาให้ครบ และขยายต่อได้ง่าย
    • ผมไม่เห็นด้วยกับมุมมองเรื่อง test บางส่วน เพราะแม้แอปเล็กๆ ก็มี โค้ดทดสอบ แล้วช่วยประหยัดเวลาได้ด้วย CI ก็แค่ไฟล์สั้นๆ สักยี่สิบบรรทัด ซึ่งผมมักเอาโค้ดเดิมมา copy-paste จากโปรเจกต์ก่อนหน้า
    • CI เป็น ตัวเร่งความเร็วการพัฒนา ควรเพิ่มเข้าโปรเจกต์ตั้งแต่เริ่มต้น
    • ผมอยากรู้ว่าในจุดไหนถึงควรย้ายมาใช้ Rails จาก Flask/Express/Sinatra/Gradio/Hono ฯลฯ
  • Rails รุ่นล่าสุดดู เงางามขึ้นเยอะ จนผมรู้สึกยินดีมาก ผมดูแลและอัปเดตแอปหลากหลายตั้งแต่ Rails 2.3 ติดต่อกัน 12 ปี ทำให้รู้สึกว่า Rails ตอนนี้เป็น โปเกมอนที่วิวัฒนาการ แบบไม่เหมือนเดิมเลย เพราะมี Rails Upgrade Guide ทำไว้ละเอียดมาก ทำให้อัปเกรดได้ต่อเนื่องโดยไม่ต้องทำ refactor ใหญ่ๆ แม้ไม่ใช่ backward compatible แต่อะไรที่เปลี่ยนแปลงเป็นข้อดีที่ มีการเอกสารชัดเจน นี่คือจุดเด่นใหญ่ การมี ActiveStorage ก็ทำให้การแนบไฟล์ดีขึ้นมาก ส่วน Webpacker transition เจอปัญหาบ้าง แต่ด้วย Import Maps คงดูง่ายขึ้นแล้ว ปีนี้ผมวางแผนอัปเกรดเป็น 8.1
    • 4 ปีก่อน ผมยอมลดค่าจ้างเพื่อรักษางานซ่อมแซมแอป Rails เก่าให้ลูกค้าที่มีงบน้อย (สมัย Ruby 2.3) ผลลัพธ์คือการอัปเกรดหรือเพิ่มฟีเจอร์ทำได้ง่ายมาก จึงรู้สึกพึงพอใจอย่างมาก
  • ผมพัฒนาโปรเจกต์โอเพนซอร์ส Rails คนเดียวที่รองรับผู้ใช้เดือนละ 120,000 คน และเห็นด้วยกับประเด็นในข้อความนั้นค่อนข้างมาก อีกประเด็นหนึ่งคือฟีเจอร์แนบไฟล์ของ ActiveStorage ทำได้ยอดเยี่ยม การ deploy ส่วนใหญ่ผมใช้ Dokku เป็นหลัก แต่ก็รอคอยที่จะลอง Kamal ดู Rail ยังคงพัฒนาต่อเนื่อง และ Ruby ก็เร็วขึ้นเรื่อยๆ
    • ถ้าคุณชอบ Dokku อยากรู้ว่าลอง Cloud Native Buildpacks แล้วหรือยัง เพราะอันนี้สร้าง OCI image ได้ทันที
  • ผมไม่ค่อยได้เรียน Ruby เนื่องจากงาน web development ไม่มาก จึงมีแต่ Django ที่คุ้นเคยอยู่เป็นหลัก จึงสงสัยว่าทั้งสองเฟรมเวิร์กต่างกันอย่างไรบ้าง
    • ผมมีประสบการณ์กับทั้งสอง ecosystem มานาน (แม้ช่วงหลังได้ทำ Rails น้อยลง) Django ผูกกับ python, Rails ผูกกับ ruby/gem ทำให้ผลกระทบจาก ecosystem สำคัญมาก Django admin CMS มีพลังชัดเจนมากกว่า Rails และองค์กรจำนวนมากใช้ django ทำ CMS ภายในทั้งหมด ส่วน Rails มี scaffolding CLI ยิ่งใหญ่มาก ทำให้สร้าง CRUD ได้เร็วมาก Rails มีระดับการ abstract สูงกว่า Django และด้วยโครงสร้าง/สถาปัตยกรรมที่ Rails กำหนดให้ค่อนข้างมาก จึงต้องเลือกเองมากกว่าใน Django ความใส่ใจเรื่อง DRY และการป้องกัน code duplication ของ Rails สูงกว่า คนที่ให้ความสำคัญกับความเป็น pythonic มักมองว่า “magic” ของ Rails เยอะเกินไป ในทางกลับกันฝั่ง Rails ก็อาจมองการซ้ำซากของ python ว่าไม่ละเอียดพอ สุดท้ายแล้วสองฝั่งต่างมีสไตล์ไม่เหมือนกัน
    • ถ้าผมจะทำเว็บแอป (consumer facing product) ผมจะหยิบ Rails มาก่อน เพราะรู้สึกว่าตั้งแต่ scaffolding ไปถึงการ ออกสู่ตลาด ทำได้ง่ายกว่า (แม้ยังไม่มีประสบการณ์กับบริการขนาดใหญ่มาก่อน) สำหรับ internal tools, งานข้อมูล และภูมิภาคข้อมูลเชิงพื้นที่ ผมคิดว่า python/django เหมาะกว่า
    • ความต่างใหญ่สุดคือ python vs ruby เอง เพราะ ecosystem ของ python ใหญ่มาก และ Django มีฟังก์ชันยืนยันตัวตนรวมถึง admin ในตัว
    • ผมคิดว่าในเชิง สภาพแวดล้อมการทดสอบ ประสบการณ์ Rails ดีกว่า เพราะ Rails มีการตั้งค่า CI และการสร้างโค้ดทดสอบให้ครบในตัว
    • จากประสบการณ์ Django Admin ใช้ง่ายและยืดหยุ่นมากกว่าทางเลือกในโลก Ruby ชัดเจน ขณะที่ด้าน testing และ routing Rails ทำได้ดีกว่าและมี convention เข้มงวดกว่า ผมชอบ ActiveRecord+arel มากกว่า Django ORM มากขึ้น (ส่วนตัวรู้สึกว่าการเขียนโค้ด Ruby สนุกกว่าการเขียนโค้ด Python)
    • เรียนรู้ Ruby ไม่ยากมาก และ Rails ให้ โครงสร้างและ convention มาให้มากกว่า Django อย่างมาก
  • มีคนจำนวนมากที่มีความผูกพันกับ Rails ใกล้เคียงกับความรู้สึกแบบ โรแมนติก มากกว่าปกติ ผมไม่ค่อยรู้สึกแบบนั้นจึงรู้สึกว่าบางทีน่าอิจฉา แต่ละ framework/ภาษามีแฟนคลับเอง แต่กระแสของ Rails ดูพิเศษกว่าอีกระดับ
    • ผมรู้สึกไม่ค่อยสะดวกกับ convention ของ Rails ในบางจุด แต่พอจะเอา productivity ที่ใกล้เคียงมาทดลองกับ JavaScript backend ผมรู้สึกแทบเป็นไปไม่ได้ ขณะเดียวกันเมื่อมีโอกาสดูแลโค้ด Rails ก็เห็นหลายครั้งที่มีการ reimplement ฟังก์ชันพื้นฐานของ Rails เอง (เช่น Active Job) ด้วยเหตุผลหลากหลาย จึงคิดว่าการเดินตาม convention มักมีประสิทธิภาพกว่าเสมอ
  • ใช้ SQLite ใน production มาแล้ว เจอปัญหาเรื่อง migration จนสุดท้ายเหนื่อยไม่น้อย เช่นการเพิ่มข้อจำกัด NOT NULL ให้คอลัมน์เดิม ต้อง recreate ตารางทั้งตารางผ่าน temporary table
    • SQLite ไม่มี ADD CONSTRAINT และไม่รองรับภาษา PL หรือ stored proc ง่ายๆ จึงต้องวนรอบกลับไปที่ host language อยู่ตลอด ซึ่งกับภาษาที่เป็น statically typed จะยุ่งยากมาก
    • ผมคิดว่า Postgres เป็นตัวเลือกที่ดีที่สุด จึงไม่น่าจะเลิกรับไว้ได้ง่ายๆ อย่างไรก็ตาม การที่ sqlite3 กลายมาเป็นตัวเลือก first-class ใน Rails ถือเป็นพัฒนาการที่ดี
    • แนวทางหลักของ Rails ที่ว่า sqlite อาจแทน redis ได้ก็มี แต่ในความเป็นจริง เหมาะแค่เริ่มบริการเล็กๆ เท่านั้น หากมีแผนย้ายไป DB ตัวอื่น ไม่ควรเริ่มด้วย sqlite เพราะ migration มักเจ็บปวดเสมอ
    • ใน Rails ใช้ ActiveRecord validation จัดการได้ส่วนใหญ่ แต่มีขอบเขตในการสะท้อนข้อจำกัดโครงสร้างที่พื้นฐานไม่ได้ครบถ้วน
  • คู่มือการติดตั้ง Ruby ค่อนข้าง ซับซ้อน พอผมมานั่งทำ jekyll blog ใหม่หลังจากผ่านไป 15 ปี ก็เจอปัญหาในการใช้ gem และเครื่องมือต่างๆ บ้าง ส่วนหนึ่งเป็นความผิดพลาดของตัวเอง แต่รู้สึกว่า ถ้าจัดการได้ง่ายขึ้นก็คงดี ข้อเท็จจริงนี้ทำให้เกิดแรงจูงใจอยากกลับมาลอง Ruby อีกครั้ง
    • การ setup ควรทำให้ทุกคน ง่าย สำหรับผมเอง Jekyll เรียนรู้เร็วเพราะในสภาพแวดล้อมเดิมมี Ruby และ RubyGems อยู่แล้ว
  • ถ้าใช้เฉพาะ sqlite ก็คงลอง litestack สักครั้ง แม้ว่าตัวเองยังไม่เคยใช้ตรงๆ แต่มีแผนย้ายโปรเจกต์ส่วนตัวจาก postgres มาเป็น litestack และ benchmark performance ของมันน่าประทับใจมาก
    • Rails 8 ทำ SQLite ให้แข็งแรงขึ้นมากแล้ว จึงสงสัยว่าต้องการ litestack จริงหรือไม่ และอยากรู้ว่ามี จุดแตกต่าง อะไร