+ การขึ้นสู่ความโดดเด่นของ Ruby on Rails เกิดจากการผสมผสานระหว่างเทคโนโลยีใหม่และจังหวะเวลาที่เหมาะสม + ข้อได้เปรียบทางเทคโนโลยีมักจะเสื่อมถอยตามกาลเวลา และจังหวะที่ดีเพียงอย่างเดียวไม่สามารถรักษาความเคลื่อนไหวในระยะยาวได้ + ดังนั้นจึงจำเป็นต้องมีการอธิบายที่กว้างขึ้นว่า Rails ยังคงรักษาความเกี่ยวข้องและขยายผลกระทบและชุมชนของมันได้อย่างไร + ฉันเสนอว่า ปัจจัยที่ทำให้ Rails ยืนหยัดและยังคงเป็นตัวขับเคลื่อนหลักคือหลักการที่ขัดแย้งกันนี้เอง +
++ หลักการนี้ได้พัฒนาไปในช่วงทศวรรษที่ผ่านมา แต่เสาหลักส่วนใหญ่ของมันก็ยังคงเป็นเสาหลักดั้งเดิม + ฉันไม่ได้อ้างว่าความคิดเหล่านี้เป็นของใหม่อย่างแท้จริง ความสำเร็จหลักของ Rails คือการรวมตัวและสร้างชุมชนที่แข็งแกร่งรอบ ๆ + ความคิดที่ท้าทายเกี่ยวกับธรรมชาติของการเขียนโปรแกรมและโปรแกรมเมอร์ +
+และต่อไปนี้คือเสาหลักทั้งเก้าที่สำคัญที่สุดของหลักการ Rails ตามความเห็นของฉันเอง
+ +จะไม่มี Rails หากไม่มี Ruby ดังนั้นจึงเหมาะสมที่หลักการแรกของความเชื่อจะถูกนำมาจากแรงจูงใจหลักในการสร้าง Ruby
+ความกบฏดั้งเดิมของ Ruby คือการยกความสุขของนักโปรแกรมขึ้นสู่จุดสูงสุด เหนือกว่าความกังวลอื่นๆ ที่แข่งขันและมีความสำคัญที่เคยผลักดันภาษาโปรแกรมและระบบนิเวศก่อนหน้ามัน
+ขณะที่ Python อาจจะอวดว่ามี "วิธีการทำสิ่งหนึ่งเพียงวิธีเดียว และดีที่สุดควรมีเพียงวิธีเดียว" Ruby กลับเพลิดเพลินกับความหลากหลายในการแสดงออกและความปราณีต ขณะที่ Java ให้ความสำคัญกับการป้องกันนักโปรแกรมจากตัวเองอย่างรุนแรง Ruby กลับมอบชุดมีดคมๆ มาพร้อมกับชุดต้อนรับ ขณะที่ Smalltalk ยืนยันความบริสุทธิ์ของการส่งข้อความ Ruby สะสมคำสั่งและโครงสร้างด้วยความต้องการที่เกือบจะเรียกได้ว่าโลภมาก
+Ruby ต่างออกไปเพราะมันให้ความสำคัญกับสิ่งที่แตกต่าง และส่วนใหญ่ของสิ่งเหล่านั้นล้วนเป็นการรับใช้ความปรารถนาสำหรับความสุขของนักโปรแกรม การตามหาที่นำมาซึ่งความขัดแย้งไม่เพียงแต่กับสภาพแวดล้อมการโปรแกรมอื่นๆ ส่วนใหญ่เท่านั้น แต่ยังรวมถึงการรับรู้ทั่วไปของสังคมว่านักโปรแกรมคืออะไรและพวกเขาควรจะทำตัวอย่างไร
+Ruby ไม่เพียงแต่ยอมรับ แต่ยังปรับตัวให้เข้ากับและยกระดับความรู้สึกของนักโปรแกรม ไม่ว่าจะเป็นความรู้สึกไม่พอใจต่อตนเอง ความกำกวม หรือความสุข Matz ข้ามผ่านอุปสรรคในการพัฒนาที่มีความซับซ้อนอย่างน่าทึ่งเพื่อให้เครื่องจักรดูเหมือนจะยิ้มและยกย่องผู้ร่วมสมรู้ร่วมคิดที่เป็นมนุษย์ Ruby เต็มไปด้วยภาพลวงตาที่สิ่งที่ดูเรียบง่าย ชัดเจน และสวยงามต่อสายตาของจิตใจเรา แท้จริงแล้วคือความยุ่งเหยิงของสายไฟใต้ฝากระโปรง การเลือกเหล่านี้ไม่ได้มาฟรีๆ (ลองถามทีม JRuby เกี่ยวกับการพยายามย้อนวิศวกรรมกล่องดนตรีนี้!), นี่แหละเหตุผลที่มันน่าชื่นชมมาก
+เป็นความทุ่มเทให้กับวิสัยทัศน์ทางเลือกสำหรับการเขียนโปรแกรมและนักโปรแกรมนี่เองที่ทำให้ผมหลงรัก Ruby มันไม่ใช่แค่ความง่ายในการใช้งาน ไม่ใช่แค่ความสวยงามของบล็อก มันไม่ใช่การบรรลุผลทางเทคนิคเพียงอย่างเดียว มันคือวิสัยทัศน์ วัฒนธรรมที่ต่อต้านกระแสหลัก สถานที่สำหรับคนที่ไม่เข้ากับกรอบการเป็นนักโปรแกรมมืออาชีพที่มีอยู่ให้รู้สึกว่าตนเองมีส่วนร่วมและสมาคมกับคนที่มีความคิดคล้ายคลึงกัน
+ผมเคยอธิบายการค้นพบ Ruby นี้ในอดีตว่าเหมือนเจอถุงมือวิเศษที่สวมกับสมองของผมได้พอดี ดีกว่าที่ผมเคยจินตนาการเกี่ยวกับการที่ถุงมือจะสวมได้พอดีเสียอีก แต่มันยังมากกว่านั้น มันเป็นจุดเปลี่ยนส่วนตัวของผมจากการ 'เขียนโปรแกรมเพราะผมต้องการโปรแกรม' ไปสู่ 'เขียนโปรแกรมเพราะผมหลงรักมันในฐานะที่เป็นการออกกำลังกายทางปัญญาและการแสดงออก' มันคือการค้นพบแหล่งน้ำพุแห่งการไหลลื่นและสามารถเปิดใช้ได้ตามอำเภอใจ สำหรับใครที่คุ้นเคยกับงานของ Csikszentmihalyi ผลกระทบของสิ่งนี้ยากที่จะประเมินค่าสูงไปกว่านี้อีกแล้ว
+ผมไม่ได้พูดเกินจริงเลยเมื่อผมบอกว่า Ruby ได้เปลี่ยนผมและกำหนดทิศทางของงานชีวิตผม การเปิดเผยนี้ลึกซึ้งมาก มันทำให้ผมมีความรู้สึกว่าได้รับการเรียกให้ทำงานเผยแผ่ในนามของการสร้างสรรค์ของ Matz เพื่อช่วยเผยแพร่การสร้างสรรค์อันลึกซึ้งนี้และประโยชน์ของมัน
+ผมเข้าใจว่าหลายคนอาจจะส่ายหัวด้วยความไม่เชื่อ ผมไม่ตำหนิคุณหรอก ถ้ามีใครมาบอกประสบการณ์นี้ให้ผมฟังตอนที่ผมยังอยู่ในวิถีที่คิดว่า "การเขียนโปรแกรมเป็นแค่เครื่องมือ" ผมก็คงจะส่ายหัวเช่นกัน และแล้วผมก็คงจะหัวเราะกับการใช้ภาษาที่เกี่ยวข้องกับศาสนาอย่างเกินเลย แต่เพื่อให้การเล่านี้เป็นเรื่องจริง มันก็ต้องมีความจริงใจ แม้ว่าสิ่งนี้จะทำให้บางคนหรืออาจจะส่วนใหญ่รู้สึกไม่สบายใจก็ตาม
+ไม่ว่าอย่างไรนี่มีความหมายอะไรกับ Rails และหลักการนี้ยังคงมีอิทธิพลต่อการพัฒนาของมันอย่างไร? เพื่อตอบคำถามนี้ ผมคิดว่ามันเป็นประโยชน์ที่จะมองไปที่หลักการอีกอย่างหนึ่งที่ถูกนำมาใช้อธิบาย Ruby ในช่วงเริ่มแรก: หลักการของการประหลาดใจน้อยที่สุด Ruby ควรจะทำงานตามที่คุณคาดหวัง สิ่งนี้สามารถอธิบายได้ง่าย ๆ ด้วยการนำมาเปรียบเทียบกับ Python:
+{% highlight ruby %} +$ irb +irb(main):001:0> exit +$ irb +irb(main):001:0> quit + +$ python +>>> exit +Use exit() or Ctrl-D (i.e. EOF) to exit +{% endhighlight %} +Ruby ยอมรับทั้ง exit และ quit เพื่อตอบสนองความต้องการที่ชัดเจนของนักโปรแกรมที่ต้องการออกจากคอนโซลแบบโต้ตอบ ในทางตรงข้าม Python จะสอนนักโปรแกรมอย่างละเอียดว่าควรจะทำอย่างไรให้ถูกต้อง แม้จะชัดเจนว่ามันรู้ว่าความหมายคืออะไร (เพราะมันแสดงข้อความแจ้งข้อผิดพลาด) นี่เป็นตัวอย่างที่ชัดเจน แม้จะเล็กน้อย ของหลักการของความประหลาดใจน้อยที่สุด (PoLS)
+เหตุผลที่หลักการของความประหลาดใจน้อยที่สุด (PoLS) เสื่อมความนิยมในชุมชน Ruby ก็เพราะหลักการนี้มีความเป็นอัตวิสัยในตัวของมันเอง ความประหลาดใจน้อยที่สุดสำหรับใคร? ก็สำหรับ Matz และคนที่รู้สึกประหลาดใจในแบบเดียวกับเขา เมื่อชุมชน Ruby ขยายใหญ่ขึ้น และเปอร์เซ็นต์ของคนที่รู้สึกประหลาดใจกับสิ่งที่ต่างจาก Matz ก็เพิ่มขึ้นด้วย ทำให้หลักการนี้กลายเป็นแหล่งของการถกเถียงไร้ประโยชน์ในกลุ่มอีเมล ดังนั้นหลักการนี้จึงถูกผลักไปอยู่เบื้องหลัง เพื่อหลีกเลี่ยงการถกเถียงที่ไม่ได้ผลว่าบุคคล X รู้สึกประหลาดใจกับพฤติกรรม Y หรือไม่
+แล้วนี่มันเกี่ยวกับ Rails อย่างไร? ก็คือ Rails ได้รับการออกแบบด้วยหลักการที่ใกล้เคียงกับหลักการของความประหลาดใจน้อยที่สุด (สำหรับ Matz) นั่นคือ หลักการของรอยยิ้มที่กว้างขึ้น (ของ DHH) ซึ่งก็คือตามที่มันบอกไว้เลย: API ที่ออกแบบมาโดยให้ความสนใจเป็นอย่างมากกับสิ่งที่จะทำให้ผมยิ้มได้กว้างขึ้น เมื่อผมเขียนมันออกมาแบบนี้ มันดูเหมือนจะเป็นการหยิ่งผยองอย่างตลกร้าย และแม้แต่ผมเองก็ยังรู้สึกว่ายากที่จะโต้แย้งกับความประทับใจแรกนี้
+แต่การสร้างสรรค์สิ่งอย่าง Ruby หรือ Rails เป็นการกระทำที่มีความหยิ่งผยองอย่างลึกซึ้งในระยะเริ่มต้นอย่างน้อยที่สุด ทั้งสองโครงการต่างก็เกิดจากความคิดของผู้สร้างเพียงคนเดียว แต่อาจจะผมเอาความต้องการของตัวเองมาสะท้อนไปที่ Matz ก็ได้ ดังนั้นผมจะจำกัดขอบเขตของการประกาศของผมให้แคบลงไปที่สิ่งที่ผมรู้: ผมสร้าง Rails เพื่อตัวผมเอง เพื่อทำให้ผมยิ้มได้ เป็นอันดับแรก ประโยชน์ของมันในหลายๆ ด้านต้องยอมจำนนต่อความสามารถของมันที่จะทำให้ชีวิตผมมีความสุขมากขึ้น เพื่อเพิ่มคุณค่าในการทำงานประจำวันของผมที่ต้องจัดการกับความต้องการและคำขอสำหรับระบบข้อมูลทางเว็บ
+เหมือนกับ Matz ผมก็มีเวลาที่ไปถึงขั้นยอมเสียสละอย่างไร้สาระเพื่อหลักการของผม ตัวอย่างหนึ่งคือ Inflector คลาสที่เข้าใจรูปแบบและความไม่สม่ำเสมอของภาษาอังกฤษเพียงพอที่จะแปลงคลาส Person ให้เป็นตาราง People, Analysis ให้เป็น Analyses และ Comment ให้เป็น Comments พฤติกรรมนี้ปัจจุบันได้รับการยอมรับเป็นส่วนหนึ่งของ Rails โดยไม่มีการตั้งคำถาม แต่ในช่วงแรกที่เรายังกำลังรวมหลักการและความสำคัญของมัน ไฟแห่งความขัดแย้งก็เผาไหม้อย่างรุนแรง
+อีกตัวอย่างหนึ่งที่ต้องใช้ความพยายามในการพัฒนาน้อยกว่า แต่ก็ก่อให้เกิดความกังวลมากไม่แพ้กัน: Array#second ถึง #fifth (และ #forty_two เพื่อเป็นการแซวอย่างแสนสนุก) ตัวเรียกใช้เหล่านี้ทำให้กลุ่มคนจำนวนมากที่มีเสียงดังออกมาประณามว่ามันทำให้โค้ดบวมขึ้น (และเกือบจะถึงจุดจบของอารยธรรมเลยทีเดียว สำหรับเรื่องนี้) ทั้งที่มันสามารถเขียนได้ง่ายๆ ว่า Array#[1], Array#[2] (และ Array[41])
+แต่ทั้งสองการตัดสินใจนั้น จนถึงทุกวันนี้ ยังคงทำให้ผมยิ้มได้ ผมสนุกกับการได้เขียน people.third ในการทดสอบหรือบนคอนโซล มันไม่เหตุผล ไม่มีประสิทธิภาพ อาจจะดูเป็นโรคจิตไปเลยด้วยซ้ำ แต่มันยังคงทำให้ผมยิ้ม ดังนั้นมันจึงเติมเต็มหลักการและทำให้ชีวิตผมมีความสุขมากขึ้น ช่วยยืนยันในการมีส่วนร่วมของผมกับ Rails ต่อเนื่องมา 12 ปีแล้ว
+ต่างจากการเพิ่มประสิทธิภาพการทำงาน การเพิ่มความสุขนั้นยากที่จะวัดผลได้ ทำให้มันเป็นการพยายามที่เกือบจะไม่มีความเป็นวิทยาศาสตร์ ซึ่งสำหรับบางคนอาจทำให้มันดูไม่สำคัญเท่า หรือไม่ก็น่ารำคาญ นักโปรแกรมถูกสอนให้โต้แย้งและเอาชนะสิ่งที่วัดได้ สิ่งที่มีข้อสรุปที่ชัดเจนและสามารถแสดงให้เห็นได้ว่าอะไรดีกว่าอะไรอย่างชัดเจน
+แต่แม้ว่าการแสวงหาความสุขจะยากที่จะวัดผลในระดับจุลภาค มันก็ชัดเจนกว่ามากในการสังเกตระดับมหภาค ชุมชน Ruby on Rails เต็มไปด้วยคนที่อยู่ที่นี่เพราะการแสวงหานี้ พวกเขายกย่องว่าชีวิตการทำงานดีขึ้น มีความสุขมากขึ้น ความสำเร็จนี้ปรากฏชัดเจนในความรู้สึกรวมกัน
+ดังนั้นเราจึงสรุปได้ว่า การเพิ่มประสิทธิภาพเพื่อความสุขอาจเป็นกุญแจสำคัญที่สุดในการก่อรูปของ Ruby on Rails และมันจะยังคงเป็นเช่นนี้ต่อไป
+หนึ่งในสโลแกนด้านการเพิ่มผลิตภาพของ Rails ในช่วงแรกกล่าวว่า: “คุณไม่ใช่หิมะเกล็ดสวยงามและเป็นเอกลักษณ์” มันเสนอว่า การละทิ้งความเป็นเอกลักษณ์ที่ไม่มีประโยชน์นั้นจะช่วยให้คุณข้ามผ่านความยุ่งยากของการตัดสินใจที่ซ้ำซาก และทำให้ก้าวหน้าได้เร็วขึ้นในพื้นที่ที่สำคัญจริง ๆ
+ใครจะสนใจว่าคีย์หลักของฐานข้อมูลของคุณถูกอธิบายด้วยรูปแบบใด? มันสำคัญจริงหรือว่ามันจะเป็น “id”, “postId”, “posts_id”, หรือ “pid”? นี่คือการตัดสินใจที่ควรพิจารณาซ้ำไปซ้ำมาไหม? ไม่
+ส่วนหนึ่งของภารกิจของ Rails คือการใช้มีดพร้าเฉือนป่าอันหนาแน่นและเติบโตอย่างต่อเนื่องของการตัดสินใจที่ต้องเผชิญกับนักพัฒนาที่สร้างระบบข้อมูลสำหรับเว็บ มีการตัดสินใจหลายพันข้อที่ต้องทำเพียงครั้งเดียว และหากใครคนอื่นสามารถทำให้คุณได้ ก็ยิ่งดี
+การเปลี่ยนแปลงจากการกำหนดค่าเป็นการตั้งค่ามาตรฐานไม่เพียงแต่ทำให้เราหลีกเลี่ยงการพิจารณาซ้ำซาก ยังเปิดโอกาสให้เราสามารถสร้างนามธรรมที่ลึกซึ้งยิ่งขึ้น หากเราสามารถพึ่งพาคลาส Person ที่จับคู่กับตาราง people เราสามารถใช้การเปลี่ยนแปลงเดียวกันนี้เพื่อจับคู่การเชื่อมโยงที่ประกาศว่า has_many :people เพื่อมองหาคลาส Person พลังของการตั้งค่ามาตรฐานที่ดี จะให้ผลตอบแทนที่หลากหลาย
+นอกเหนือจากการเพิ่มผลิตภาพสำหรับผู้เชี่ยวชาญแล้ว การตั้งค่ามาตรฐานยังลดอุปสรรคในการเข้าสำหรับผู้เริ่มต้น มีการตั้งค่ามาตรฐานมากมายใน Rails ที่ผู้เริ่มต้นไม่จำเป็นต้องรู้ แต่สามารถได้รับประโยชน์จากมันในความไม่รู้ มันเป็นไปได้ที่จะสร้างแอปพลิเคชันที่ยอดเยี่ยมโดยไม่รู้ว่าทำไมทุกอย่างถึงเป็นอย่างที่เป็น
+สิ่งนี้เป็นไปไม่ได้หากเฟรมเวิร์กของคุณเป็นเพียงตำราเรียนหนาและแอปพลิเคชันใหม่ของคุณเป็นกระดาษเปล่า มันต้องใช้ความพยายามอย่างมหาศาลในการหาวิธีและจุดเริ่มต้น
+เมื่อมีแนวทางที่ชัดเจนสำหรับทุกการเปลี่ยนแปลงแต่ละครั้ง เราสามารถไปตามส่วนต่าง ๆ ของแอปพลิเคชันที่เหมือนหรือคล้ายกับแอปพลิเคชันอื่น ๆ ที่มาก่อนหน้าได้อย่างรวดเร็ว ทุกสิ่งมีที่ของมันและทุกสิ่งอยู่ในที่ของมัน ข้อจำกัดช่วยปลดปล่อยแม้แต่จิตใจที่มีความสามารถที่สุด
+อย่างไรก็ตาม พลังของการตั้งค่ามาตรฐานไม่ได้ปราศจากอันตราย เมื่อ Rails ทำให้มันง่ายเกินไปในการทำหลายสิ่งหลายอย่าง เรามักจะคิดว่าแง่มุมทุกอย่างของแอปพลิเคชันสามารถสร้างจากแม่แบบที่ตัดไว้ล่วงหน้า แต่แอปพลิเคชันที่คุ้มค่าที่จะสร้างมักจะมีบางส่วนที่เป็นเอกลักษณ์ในบางวิธี อาจจะเพียง 5% หรือ 1% แต่ก็มีอยู่
+สิ่งที่ยากคือการรู้ว่าเมื่อไหร่ควรเบี่ยงเบนจากการตั้งค่ามาตรฐาน การเบี่ยงเบนที่มีความสำคัญพอสมควรที่จะต้องมีการออกนอกเส้นทางหรือไม่? ฉันเชื่อว่าความคิดที่จะเป็นหิมะเกล็ดสวยงามและเป็นเอกลักษณ์ส่วนใหญ่เป็นความคิดที่ไม่ดี และต้นทุนของการออกนอก Rails นั้นต่ำกว่าที่ควรจะเป็น แต่ก็ยังมีบางกรณีที่คุณต้องพิจารณาทุกกรณีอย่างรอบคอบ
+คุณจะรู้ได้อย่างไรว่าควรสั่งอะไรในร้านอาหารเมื่อคุณไม่รู้ว่าอะไรดี? ถ้าคุณปล่อยให้เชฟเลือกให้ คุณก็สามารถคาดหวังได้ว่าจะได้รับมื้ออาหารที่ดีได้ แม้ว่าคุณจะยังไม่รู้ว่า "ดี" คืออะไร นั่นคือการ "โอมากาเสะ" ซึ่งเป็นวิธีการรับประทานอาหารที่ดี โดยที่คุณไม่จำเป็นต้องเป็นผู้เชี่ยวชาญในด้านอาหารหรือพึ่งพาดวงในการเลือกอาหาร
+สำหรับการเขียนโปรแกรม ประโยชน์ของการปฏิบัตินี้ (การให้ผู้อื่นเลือก stack ให้คุณ) คล้ายกับที่เราได้รับจากหลักการ Convention over Configuration แต่ในระดับที่สูงขึ้น โดยที่ CoC เน้นที่วิธีการที่เราจะใช้เฟรมเวิร์กแต่ละตัวได้ดีที่สุด ในขณะที่โอมากาเสะมุ่งเน้นไปที่การเลือกเฟรมเวิร์ก และวิธีที่เฟรมเวิร์กเหล่านั้นจะทำงานร่วมกันได้
+สิ่งนี้ขัดแย้งกับประเพณีที่เคารพนับถือในการเขียนโปรแกรม ซึ่งมักนำเสนอเครื่องมือต่าง ๆ ให้เป็นตัวเลือกแบบแยกส่วน และมอบสิทธิพิเศษ (และภาระ!) ให้กับโปรแกรมเมอร์แต่ละคนในการตัดสินใจเลือกเครื่องมือเอง
+คุณคงเคยได้ยิน และอาจจะเห็นด้วยกับคำว่า "ใช้เครื่องมือที่ดีที่สุดสำหรับงาน" ฟังดูเหมือนเป็นหลักการพื้นฐานที่ไม่น่าจะมีข้อโต้แย้งอะไร แต่การเลือก "เครื่องมือที่ดีที่สุด" นั้นขึ้นอยู่กับพื้นฐานที่ช่วยให้เราตัดสินใจได้อย่างมั่นใจว่าอะไรคือ "ดีที่สุด" ซึ่งจริง ๆ แล้วมันยากกว่าที่คิดไว้
+มันเป็นปัญหาที่คล้ายกับการเลือกอาหารในร้านอาหาร และเช่นเดียวกับการเลือกแต่ละคอร์สในมื้ออาหารแบบแปดคอร์ส การเลือกไลบรารี่หรือเฟรมเวิร์กแต่ละตัวไม่ใช่งานที่ทำแยกออกจากกัน เป้าหมายในทั้งสองกรณีคือการพิจารณาทั้งคืนหรือทั้งระบบโดยรวม
+ดังนั้นกับ Rails เราจึงตัดสินใจลดทอนสิ่งที่ดีอย่างหนึ่งลง นั่นคือสิทธิพิเศษของโปรแกรมเมอร์ในการเลือกเครื่องมือแต่ละชิ้นในกล่องของพวกเขา เพื่อสิ่งที่ดียิ่งกว่า: กล่องเครื่องมือที่ดีกว่าสำหรับทุกคน ซึ่งผลลัพธ์ที่ได้ก็มากมาย:
+เพราะแม้แต่โปรแกรมเมอร์ที่มีความรู้และทักษะมากที่สุดที่เข้ามาและยังคงอยู่ใน Rails ก็ไม่น่าจะต่อต้านทุกเรื่องในเมนู (ถ้าพวกเขาต่อต้าน พวกเขาก็คงไม่อยู่กับ Rails) ดังนั้นพวกเขาจึงเลือกการเปลี่ยนแปลงด้วยความระมัดระวัง และจากนั้นก็ไปเพลิดเพลินกับส่วนที่เหลือของสแต็กที่ถูกจัดเตรียมและแชร์ร่วมกับคนอื่น ๆ ต่อไป
+มีความดึงดูดทางอารมณ์อย่างมากในการเลือกแนวคิดหลักเพียงแนวคิดเดียวและติดตามมันไปจนถึงข้อสรุปที่เป็นเหตุผลให้เป็นโครงสร้างพื้นฐานของสถาปัตยกรรม มีความบริสุทธิ์ในระเบียบวินัยเช่นนี้ ดังนั้นจึงชัดเจนว่าทำไมนักโปรแกรมจึงถูกดึงดูดธรรมชาติไปสู่แสงสว่างนี้
+Rails ไม่ได้เป็นแบบนั้น มันไม่ใช่เศษผ้าที่ถูกตัดเย็บมาจากแบบเดียวที่สมบูรณ์แบบ มันเป็นผ้าปัก มีการรวมกันของแนวคิดและแม้แต่กรอบการทำงานที่แตกต่างกันมากมาย หลายอย่างที่มักจะเห็นว่าขัดแย้งกัน ถ้าหากนำมาเทียบกันทีละอย่าง แต่นั่นไม่ใช่สิ่งที่เรากำลังพยายามทำ เราไม่ได้มุ่งมั่นที่จะเป็นการแข่งขันของแนวคิดที่เหนือกว่า ซึ่งต้องมีผู้ชนะเพียงคนเดียว
+ลองมาดูที่เทมเพลตที่เราสร้างสำหรับการแสดงผลในส่วนของ view ใน MVC ของ Rails ดูสิ โดยปริยายแล้ว ทุกตัวช่วยที่ช่วยเราดึงโค้ดออกจากเทมเพลตเหล่านี้เป็นแค่ฟังก์ชันหลาย ๆ ตัว! มันคือเนมสเปซเดียว ความตกใจและความหวาดกลัว มันเหมือนกับซุป PHP!
+แต่ผมขอยืนยันว่า PHP ทำให้ถูกต้องเมื่อพูดถึงการนำเสนอฟังก์ชันเฉพาะที่หายากมากที่จะต้องโต้ตอบกัน อย่างที่มักจะมีนามธรรมในเทมเพลตสำหรับการแสดงผล และสำหรับวัตถุประสงค์นี้ เนมสเปซเดียว เมธอดหลาย ๆ เมธอด ไม่เพียงแต่เป็นตัวเลือกที่เหมาะสมเท่านั้น แต่ยังเป็นตัวเลือกที่ดีมากด้วย
+นี่ไม่ได้หมายความว่าเราไม่เคยอยากจะใช้อะไรที่มีความเป็นวัตถุมากขึ้นในการสร้าง view แนวคิดของ Presenters ซึ่งเราห่อหุ้มวิธีการมากมายที่มีความสัมพันธ์ซึ่งกันและกันและกับข้อมูลข้างล่างมัน อาจจะเป็นวิธีแก้ที่สมบูรณ์แบบสำหรับซุปเมธอดที่เน่าเสียจากความขึ้นต่อกัน แต่โดยทั่วไปแล้ว มันพิสูจน์ให้เห็นว่าเป็นการใช้งานที่หายากมากกว่าที่จะเป็นเรื่องปกติ
+ในทางตรงกันข้าม เรามักจะมองว่า model ในชั้น MVC เป็นป้อมปราการหลักของความดีงามแบบเชิงวัตถุ การหาชื่อที่เหมาะสมสำหรับวัตถุ การเพิ่มความสอดคล้อง และการลดการผูกพันนั้นเป็นความสนุกของการสร้างแบบจำลองโดเมน มันเป็นชั้นที่แตกต่างอย่างมากจาก view ดังนั้นเราจึงใช้วิธีการที่แตกต่างกัน
+แต่แม้แต่ที่นี่ เราก็ไม่ได้ยึดมั่นตามหลักการปฏิบัติของแนวคิดเดียว Rails concerns ซึ่งเป็นการพัฒนาต่อจาก Ruby's mixins มักถูกใช้เพื่อให้แต่ละโมเดลมีพื้นที่ผิวที่กว้างขวางมาก สิ่งนี้เข้ากันได้ดีกับรูปแบบ Active Record โดยการให้เมธอดที่เกี่ยวข้องสามารถเข้าถึงข้อมูลและการจัดเก็บที่พวกมันมีปฏิสัมพันธ์ได้โดยตรง
+แม้แต่พื้นฐานของกรอบงาน Active Record ยังทำให้นักบริสุทธินิยมบางคนรู้สึกขัดใจ เรากำลังผสมเอาตรรกะที่จำเป็นในการสื่อสารกับฐานข้อมูลโดยตรงเข้ากับโดเมนธุรกิจและตรรกะ การรวมเขตแดนเช่นนี้! ใช่ เพราะมันพิสูจน์แล้วว่าเป็นวิธีที่มีประสิทธิภาพในการจัดการกับแอปพลิเคชันเว็บที่เกือบจะต้องสื่อสารกับฐานข้อมูลบางประเภทเสมอเพื่อรักษาสถานะของแบบจำลองโดเมน
+การมีความยืดหยุ่นในอุดมการณ์เช่นนี้นี่เองที่ทำให้ Rails สามารถรับมือกับปัญหาที่หลากหลายได้ แนวคิดเดี่ยวๆ ส่วนใหญ่ทำงานได้ดีในพื้นที่ปัญหาบางส่วน แต่จะกลายเป็นอาการไม่สะดวกหรือแข็งทื่อเมื่อนำไปใช้นอกเหนือจากพื้นที่ที่มันสบายใจ โดยการนำแนวคิดที่ซ้อนทับกันหลายแบบมาใช้ เราจึงสามารถปกป้องด้านข้างและด้านหลัง โครงสร้างสุดท้ายจึงแข็งแกร่งและมีความสามารถมากกว่าที่แนวคิดใดแนวคิดหนึ่งจะทำได้
+อย่างไรก็ตาม ค่าใช้จ่ายของความสัมพันธ์ที่หลากหลายกับแนวคิดการเขียนโปรแกรมนี้คือความซับซ้อนทางความคิด เพียงแค่รู้จักการเขียนโปรแกรมแบบวัตถุเท่านั้นไม่เพียงพอที่จะสนุกกับ Rails คุณยังควรมีประสบการณ์ในการเขียนแบบขั้นตอนและฟังก์ชันอีกด้วย
+สิ่งนี้ยังใช้ได้กับภาษาย่อยๆ ของ Rails เช่นกัน เราไม่ได้พยายามป้องกันคุณมากนักจากการต้องเรียนรู้ เช่น JavaScript สำหรับ view หรือ SQL สำหรับการค้นหาที่ซับซ้อนบางครั้ง อย่างน้อยก็เพื่อให้สามารถบรรลุถึงยอดของความเป็นไปได้
+วิธีลดภาระในการเรียนรู้บางส่วนคือการทำให้เริ่มต้นได้ง่าย ทำให้สร้างสรรค์สิ่งที่มีคุณค่าจริง ๆ ก่อนที่คุณจะเข้าใจทุกแง่มุมของกรอบงาน เราจึงมีการเร่งรีบไปสู่ Hello World เพราะเหตุนี้เอง โต๊ะของคุณถูกจัดเตรียมไว้แล้วและมีอาหารเรียกน้ำย่อยให้
+ความคิดคือการให้สิ่งที่มีคุณค่าจริง ๆ ตั้งแต่เนิ่น ๆ เราจะสนับสนุนให้ผู้ใช้ Rails พัฒนาตัวเองอย่างรวดเร็ว ยอมรับการเดินทางของการเรียนรู้ให้เป็นความสุข ไม่ใช่อุปสรรค
+เราเขียนโค้ดไม่ใช่เพียงเพื่อให้คอมพิวเตอร์หรือโปรแกรมเมอร์คนอื่นเข้าใจเท่านั้น แต่ยังเพื่อชื่นชมความงดงามอันอบอุ่นด้วย โค้ดที่สวยงามในเชิงสุนทรียะ มีคุณค่าในตัวเองและควรถูกไล่ตามด้วยความมุ่งมั่น นั่นไม่ได้หมายความว่าโค้ดที่สวยงามจะสำคัญเหนือข้อพิจารณาอื่นเสมอไป แต่มันควรมีที่นั่งเต็มตัวบนโต๊ะของลำดับความสำคัญ
+แล้วโค้ดที่สวยงามคืออะไรล่ะ? ในภาษา Ruby มันมักจะอยู่ที่จุดตัดระหว่างสำนวนแบบฉบับของ Ruby เองกับพลังของภาษาที่เจาะจงต่อโดเมน (domain-specific language) แบบกำหนดเอง มันเป็นเส้นแบ่งที่คลุมเครือ แต่ก็คุ้มค่าที่จะลองเต้นรำอยู่บนนั้น
+นี่คือตัวอย่างง่าย ๆ จาก Active Record:
+{% highlight ruby %} +class Project < ApplicationRecord + belongs_to :account + has_many :participants, class_name: 'Person' + validates_presence_of :name +end +{% endhighlight %} +นี่ดูเหมือนจะเป็น DSL แต่จริง ๆ แล้วมันก็เป็นแค่การกำหนดคลาสที่มีการเรียกเมธอดระดับคลาสสามตัวซึ่งรับสัญลักษณ์และออปชัน ไม่มีอะไรซับซ้อนที่นี่ แต่มันดูสวยจริง ๆ และเรียบง่ายจริง ๆ มันมอบพลังและความยืดหยุ่นอย่างมากมายจากเพียงไม่กี่คำประกาศนั้น
+ส่วนหนึ่งของความงามมาจากการเรียกใช้งานเหล่านี้ที่ให้เกียรติหลักการก่อนหน้า เช่น Convention over Configuration เมื่อเราเรียก belongs_to :account เรากำลังสมมติว่าคีย์ต่างประเทศมีชื่อว่า account_id และอยู่ในตาราง projects เมื่อเราต้องกำหนด class_name ของ Person ให้กับบทบาทของสมาคม participants เราต้องการเพียงคำจำกัดความชื่อคลาสนั้นเท่านั้น จากสิ่งนั้นเราจะอนุมาน (อีกครั้ง) คีย์ต่างประเทศและจุดกำหนดค่าต่าง ๆ อื่น ๆ ได้
+นี่คือตัวอย่างอีกอันจากระบบไมเกรชันฐานข้อมูล:
+{% highlight ruby %} +class CreateAccounts < ActiveRecord::Migration + def change + create_table :accounts do |t| + t.integer :queenbee_id + t.timestamps + end + end +end +{% endhighlight %} +นี่แหละคือแก่นแท้ของพลังของเฟรมเวิร์ก โปรแกรมเมอร์ประกาศคลาสตามธรรมเนียมบางอย่าง เช่น ซับคลาสของ ActiveRecord::Migration ที่มีเมธอด #change และเฟรมเวิร์กก็สามารถจัดการงานเบื้องหลังทั้งหมดที่เกี่ยวข้องได้ และรู้ว่านี่คือเมธอดที่ต้องเรียกใช้
+สิ่งนี้ทำให้นักพัฒนามีโค้ดที่ต้องเขียนน้อยมาก ในกรณีของการทำไมเกรชัน ไม่เพียงแต่จะช่วยให้สามารถเรียกใช้คำสั่ง rails db:migrate เพื่ออัปเกรดฐานข้อมูลเพื่อเพิ่มตารางใหม่นี้ได้เท่านั้น แต่ยังช่วยให้สามารถทำในทางกลับกันคือการลบตารางนี้ได้ด้วยการเรียกอีกคำสั่งหนึ่งซึ่งแตกต่างอย่างมากจากการที่นักพัฒนาต้องทำให้ทุกอย่างเกิดขึ้นเองและประกอบเวิร์กโฟลว์จากไลบรารีที่พวกเขาเรียกใช้ด้วยตัวเอง
+บางครั้งโค้ดที่งามตาก็แยบยลกว่านั้น มันไม่ได้เกี่ยวกับการทำให้บางสิ่งสั้นหรือทรงพลังที่สุดเท่าที่จะเป็นไปได้เท่านั้น แต่เป็นเรื่องของการทำให้จังหวะของคำประกาศลื่นไหล
+คำสั่งสองบรรทัดนี้ทำงานเหมือนกัน:
+{% highlight ruby %} +if people.include? person +... +if person.in? people +{% endhighlight %} +แต่จังหวะการเล่าและจุดโฟกัสต่างกันอย่างแนบเนียน ในประโยคแรกจุดโฟกัสอยู่ที่คอลเลกชัน นั่นคือประธานของเรา ส่วนในประโยคที่สองประธานชัดเจนว่าเป็น "คน" ทั้งสองประโยคยาวพอๆ กัน แต่ผมขอยืนยันว่าประโยคที่สองงดงามกว่ามาก และมีแนวโน้มจะทำให้ผมยิ้มได้เมื่อถูกใช้ในจุดที่เงื่อนไขพูดถึงคน
+Ruby มีมีดคม ๆ อยู่มากมายในลิ้นชักของฟีเจอร์ต่างๆ ไม่ใช่เรื่องบังเอิญ แต่เป็นการออกแบบ ตั้งใจไว้ ตัวอย่างที่โด่งดังที่สุดคือการ monkey patching: พลังในการเปลี่ยนแปลงคลาสและเมธอดที่มีอยู่แล้ว
+พลังนี้มักถูกเย้ยหยันว่ามากเกินไปสำหรับ โปรแกรมเมอร์ที่เป็นเพียงมนุษย์ธรรมดาจะรับมือได้ ผู้คนจากสภาพแวดล้อมที่จำกัดมากกว่า เคยจินตนาการถึงหายนะสารพัดที่จะทำให้ Ruby ต้องล่มสลาย เพราะความไว้วางใจอันมหาศาลที่ภาษานี้มอบให้กับผู้ใช้ผ่านฟีเจอร์นี้
+ถ้าคุณสามารถเปลี่ยนแปลงอะไรก็ได้ อะไรจะหยุดคุณไม่ให้ไปเขียนทับ String#capitalize เพื่อให้ "something bold".capitalize คืนค่าเป็น "Something Bold" แทนที่จะเป็น "Something bold"? นั่นอาจใช้ได้ในแอปพลิเคชันของคุณเอง แต่จากนั้นก็อาจทำให้โค้ดเสริมต่าง ๆ ที่พึ่งพาการทำงานตามเดิมพังได้
+ไม่มีอะไร นั่นแหละคำตอบ ไม่มีอะไรในเชิงโปรแกรมใน Ruby ที่จะหยุดคุณไม่ให้ใช้มีดคมของมันตัดขาดจากเหตุผล เราบังคับใช้สติสัมปชัญญะเช่นนั้นด้วยธรรมเนียม การกระตุ้นเตือน และการศึกษาไม่ใช่ด้วยการแบนมีดคมออกจากห้องครัวแล้วบังคับให้ทุกคนใช้ช้อนหั่นมะเขือเทศ
+เพราะอีกด้านหนึ่งของการทำ monkey patching คือพลังในการทำสิ่งมหัศจรรย์อย่าง 2.days.ago (ซึ่งจะคืนค่าวันที่ย้อนหลังไปสองวันจากปัจจุบัน) ตอนนี้คุณอาจคิดว่านั่นเป็นการแลกเปลี่ยนที่แย่ ว่าคุณยอมเสีย 2.days.ago ดีกว่า หากนั่นหมายถึงการป้องกันไม่ให้นักเขียนโปรแกรมเขียนทับ String#capitalize ถ้านั่นคือจุดยืนของคุณ ก็เป็นไปได้ว่า Ruby อาจไม่เหมาะกับคุณ
+กระนั้นก็ตาม คงยาก—แม้สำหรับคนที่ยอมสละเสรีภาพบางส่วนเพื่อความปลอดภัย—ที่จะโต้แย้งว่าพลังในการเปลี่ยนแปลงคลาสและเมธอดแกนกลางได้ทำให้ Ruby ในฐานะภาษาเสื่อมลง ตรงกันข้ามภาษาได้เฟื่องฟูขึ้นก็เพราะมันเสนอทัศนะที่แตกต่างและสุดขั้วต่อบทบาทของโปรแกรมเมอร์: ว่าพวกเขาสามารถถูกไว้วางใจให้ถือมีดคม ๆ ได้
+และไม่ใช่แค่ได้รับความไว้วางใจเท่านั้น แต่ยังได้รับการสอนวิธีใช้เครื่องมือที่ทรงประสิทธิภาพเช่นนั้นด้วย เพื่อที่เราจะยกระดับทั้งวิชาชีพ โดยตั้งสมมติฐานว่าคนส่วนใหญ่ในสายโปรแกรมเมอร์ย่อมอยากพัฒนาตัวเองให้เป็นโปรแกรมเมอร์ที่เก่งขึ้น สามารถใช้มีดคมกริบได้โดยไม่ตัดนิ้วตัวเองนั่นเป็นแนวคิดที่มุ่งหวังสูงอย่างยิ่ง และยังขัดกับสามัญสำนึกของโปรแกรมเมอร์จำนวนไม่น้อยเกี่ยวกับโปรแกรมเมอร์คนอื่น ๆ อีกด้วย
+เพราะทุกครั้งที่มีการถกเถียงกันเรื่องคุณค่าของ "มีดคม" มันมักจะเป็นเรื่องของโปรแกรมเมอร์คนอื่นเสมอ ผมยังไม่เคยได้ยินสักครั้งว่าโปรแกรมเมอร์คนไหนยกมือขึ้นแล้วพูดว่า “ผมไว้ใจตัวเองกับอำนาจแบบนี้ไม่ได้ กรุณาเอามันไปจากผมเถอะ!” มันจะเป็นแบบว่า “ผมคิดว่าโปรแกรมเมอร์คนอื่นจะใช้สิ่งนี้ในทางที่ผิด” อยู่เสมอ แนวคิดแบบพ่อปกครองลูกแบบนั้นไม่เคยดึงดูดใจผมเลย
+นั่นพาเรามาถึง Rails มีดที่เฟรมเวิร์กมอบให้นั้นไม่ได้คมกริบเท่ากับที่ตัวภาษาเสนอมา แต่บางเล่มก็ยังคมพอจะบาดได้อยู่ดี เราจะไม่ขอโทษที่รวมเครื่องมือแบบนี้ไว้ในชุดด้วย จริง ๆ แล้ว เราควรเฉลิมฉลองที่เรามีศรัทธามากพอในความมุ่งมั่นของโปรแกรมเมอร์เพื่อนร่วมวิชาชีพของเรา จนกล้าไว้วางใจพวกเขา
+ฟีเจอร์มากมายใน Rails ถูกถกเถียงกันมาตลอดว่าเป็น "อิสระมากเกินไป" แต่ตัวอย่างหนึ่งที่กำลังเป็นที่นิยมในตอนนี้คือ the feature of concerns. นี่คือชั้นบาง ๆ ของ syntactic sugar ครอบฟีเจอร์โมดูลที่มีอยู่ในตัวของ Ruby และถูกออกแบบมาเพื่อให้คลาสเดียวสามารถห่อหุ้มประเด็นย่อยที่เกี่ยวข้องกันหลายอย่าง แต่เข้าใจได้อย่างอิสระแยกจากกัน (จึงเป็นที่มาของชื่อ)
+ข้อกล่าวหาคือ concerns ทำให้นักพัฒนามีแนวโน้มจะยัดเยียดอ็อบเจกต์ของตนด้วยลิ้นชักชุดใหม่เอี่ยมเพื่อยัดของรกๆ ลงไปซึ่งก็จริง Concerns สามารถถูกใช้แบบนั้นได้จริงๆ
+แต่ความเข้าใจผิดอันใหญ่หลวงคือการคิดว่า ด้วยการ ไม่จัดให้มีฟีเจอร์อย่าง concerns ซึ่งเมื่ออยู่ในมือที่แม้จะมีความสามารถเพียงเล็กน้อยก็ยังสามารถแยกแนวคิดออกจากกันได้อย่างสง่างามบางส่วน เราจะพานักพัฒนาไปสู่เส้นทางแห่งสถาปัตยกรรมอันเลอเลิศ ถ้าคุณไม่อาจวางใจได้ว่าจะกันอ่างล้างจานออกจาก concerns ที่ยัดเยียดเกินพอดีของคุณได้ คุณก็คงไม่อาจลงเอยด้วยสัญลักษณ์แห่งความงามสง่าที่เปล่งประกายได้อยู่ดี
+โปรแกรมเมอร์ที่ยังไม่เคยเรียนรู้การใช้มีดคม ๆ ก็ยังไม่อาจทำเมอแรงก์ได้ในตอนนี้ คำสำคัญคือ: ตอนนี้เท่านั้น ผมเชื่อว่าโปรแกรมเมอร์ทุกคนมีหนทาง—หากไม่เรียกว่าสิทธิ—ที่จะพัฒนาจนกลายเป็นโปรแกรมเมอร์ Ruby และ Rails ที่มีความสามารถอย่างเต็มที่ และเมื่อพูดว่า "มีความสามารถ" ผมหมายถึงมีความรู้พอที่จะตระหนักได้ว่า เมื่อไร และอย่างไร ตามบริบทของตนเอง ควรใช้เครื่องมือที่แตกต่างกันเหล่านั้น ซึ่งบางชิ้นก็อันตราย อยู่ในลิ้นชัก
+นั่นไม่ได้หมายความว่าปฏิเสธความรับผิดชอบในการช่วยพาพวกเขาไปถึงจุดนั้น ภาษาและกรอบงานควรเป็นครูที่อดทน พร้อมจะช่วยและชี้แนะแก่ใครก็ตามให้ก้าวสู่ความเชี่ยวชาญ ทั้งยังตระหนักว่าหนทางที่ไว้ใจได้เพียงทางเดียวต้องผ่านดินแดนแห่งความผิดพลาด: การใช้เครื่องมือผิดวิธี เหงื่อ เลือด และบางทีน้ำตาบ้าง ไม่มีทางลัดอื่นใดจริง ๆ
+Ruby on Rails คือสภาพแวดล้อมสำหรับเชฟและผู้ที่ต้องการเป็นเชฟ คุณอาจเริ่มจากการล้างจาน แต่คุณสามารถไต่เต้าขึ้นไปจนถึงระดับที่ดูแลครัวได้ อย่าให้ใครบอกคุณได้ว่าคุณไม่อาจคู่ควรกับเครื่องมือที่ดีที่สุดในสายอาชีพนี้ในระหว่างการเดินทางของคุณ
+Rails ใช้งานได้ในหลายบริบท แต่รักแรกของมันคือการสร้างระบบแบบบูรณาการ: มอโนลิธอันยิ่งใหญ่! ระบบทั้งชุดที่จัดการกับปัญหาทั้งหมด การใช้งานเช่นนี้หมายความว่า Rails ใส่ใจทุกอย่างตั้งแต่ JavaScript ฝั่งหน้าบ้านที่จำเป็นสำหรับการอัปเดตแบบเรียลไทม์ ไปจนถึงวิธีที่ฐานข้อมูลถูกย้ายข้อมูล (migrate) จากเวอร์ชันหนึ่งไปยังอีกเวอร์ชันหนึ่งในสภาพแวดล้อมการใช้งานจริง (production)
+นั่นเป็นขอบเขตที่กว้างมาก อย่างที่เราได้คุยกันไป แต่ก็ไม่กว้างเกินกว่าจะเป็นจริงสำหรับคนคนเดียวที่จะทำความเข้าใจได้ Rails มุ่งหมายโดยเฉพาะที่จะช่วยให้บุคคลสายงานกว้างสามารถสร้างระบบครบชุดเหล่านี้ได้ จุดประสงค์ของมันไม่ได้จะผลักผู้เชี่ยวชาญให้ไปอยู่ในมุมแคบ ๆ แล้วทำให้จำเป็นต้องมีทั้งทีมของผู้เชี่ยวชาญเหล่านั้นเพื่อจะสร้างสิ่งที่มีคุณค่าอย่างยั่งยืน
+การมุ่งเน้นที่การเสริมพลังให้แก่ปัจเจกนี่เองที่ชี้ไปยังระบบแบบบูรณาการ ในระบบแบบบูรณาการ เราสามารถตัดทอนนามธรรมที่ไม่จำเป็นจำนวนมาก ลดความซ้ำซ้อนระหว่างเลเยอร์ (เช่น เทมเพลตที่อยู่ทั้งบนเซิร์ฟเวอร์และฝั่งไคลเอนต์) และเหนือสิ่งอื่นใด หลีกเลี่ยงการกระจายระบบของเรา ก่อนที่เราจะจำเป็นต้องทำจริง ๆ อย่างถึงที่สุด
+ความซับซ้อนจำนวนมากในการพัฒนาระบบเกิดจากการเพิ่มขอบเขตใหม่ระหว่างองค์ประกอบต่าง ๆ ที่จำกัดวิธีที่คุณจะเรียกใช้งานระหว่าง A และ B การเรียกเมธอดระหว่างอ็อบเจ็กต์นั้นง่ายกว่ามาก เมื่อเทียบกับการเรียกกระบวนการจากระยะไกลระหว่างไมโครเซอร์วิส มีโลกใบใหม่แห่งความปวดหัวทั้งสถานะความล้มเหลว ปัญหาความหน่วง และตารางการอัปเดตการพึ่งพา คอยรอผู้ที่บุกเข้าไปในรังแห่งการกระจายตัวอยู่
+บางครั้งการกระจายแบบนี้ก็จำเป็นจริงๆ หากคุณต้องการสร้าง API ให้กับแอปเว็บของคุณเพื่อให้คนอื่นเรียกใช้งานผ่าน HTTP ก็ต้องยอมรับและจัดการกับประเด็นเหล่านี้หลายอย่าง (ถึงแม้การรับคำขอขาเข้าจะง่ายกว่าส่งคำขอขาออกมาก—เวลาเกิด downtime ความล้มเหลวจะอยู่ที่ฝั่งคนอื่น!) แต่ถึงอย่างนั้น มันก็ยังเป็นความเสียหายที่จำกัดต่อประสบการณ์การพัฒนาของคุณเอง
+สิ่งที่แย่กว่านั้นคือเมื่อระบบถูกแยกออกก่อนเวลาอันควร และแตกออกเป็นบริการ หรือที่แย่ไปกว่านั้นคือไมโครเซอร์วิส แรงผลักดันนี้มักเริ่มจากความเข้าใจผิดว่าหากต้องการสร้างแอปพลิเคชันอินเทอร์เน็ตสมัยใหม่ คุณจำเป็นต้องสร้างระบบซ้ำหลายครั้ง: ครั้งหนึ่งบนฝั่งเซิร์ฟเวอร์ ครั้งหนึ่งบนไคลเอนต์ฝั่ง JavaScript MVC ครั้งหนึ่งสำหรับแต่ละแอปมือถือแบบเนทีฟ และอื่นๆ นี่ย่อมไม่ใช่กฎของธรรมชาติมันไม่จำเป็นต้องเป็นเช่นนั้น
+มันเป็นไปได้อย่างเต็มที่ที่จะใช้ชิ้นส่วนขนาดใหญ่ของทั้งแอปพลิเคชันร่วมกันระหว่างหลายแอปและการเข้าถึงต่าง ๆ ใช้คอนโทรลเลอร์และวิวเดียวกันสำหรับเว็บเดสก์ท็อปเหมือนกับที่ฝังอยู่ในแอปมือถือเนทีฟ รวมศูนย์ให้ได้มากที่สุดภายในโมโนลิธอันรุ่งโรจน์และสง่างามนั้น: ระบบแบบบูรณาการ
+ทั้งหมดนี้โดยแทบไม่ต้องเสียสละอะไรเลยในแง่ของความเร็ว ประสบการณ์ผู้ใช้ หรือคุณลักษณะอื่น ๆ ที่มักหลอกล่อนักพัฒนาให้รีบกระจายตัวก่อนเวลาอันควร
+นั่นแหละคือ "มีเกือบทุกอย่าง" ที่เรามุ่งหา: พลังทั้งหมดของแอปพลิเคชันที่ถูกปรับแต่งให้เหมาะกับแต่ละบุคคลและกระจายตัว แต่ยังคงไว้ซึ่งความง่ายในการใช้งานและความเข้าใจแบบเดียวกับระบบแบบบูรณาการหนึ่งเดียว
+เมื่อระบบมีอายุมากกว่าสิบปี อย่างที่ Rails เป็นมา แนวโน้มตามธรรมชาติของมันคือการแข็งตัวตายตัว มีเหตุผลนับล้านว่าทำไมการเปลี่ยนแปลงทุกอย่างอาจกลายเป็นปัญหาสำหรับใครบางคนที่ไหนสักแห่งที่พึ่งพาพฤติกรรมเดิม และนั่นก็เป็นเหตุผลที่ยุติธรรมด้วยสำหรับปัจเจกบุคคล
+แต่หากเราตั้งใจฟังเสียงของแนวคิดอนุรักษนิยมมากเกินไป เราจะไม่มีวันได้เห็นว่าสิ่งที่อยู่อีกฝั่งคืออะไร เราต้องกล้าที่จะทำลายกรอบและเปลี่ยนแปลงวิถีเดิมบ้างเป็นครั้งคราวเพื่อให้วิวัฒน์และเติบโต การวิวัฒน์นี้เองที่จะทำให้ Rails พร้อมสำหรับการอยู่รอดและความรุ่งเรืองในทศวรรษต่าง ๆ ที่จะมาถึง
+ทั้งหมดนี้เข้าใจได้ง่ายในทางทฤษฎี แต่ยากกว่ามากที่จะยอมรับได้ในทางปฏิบัติ ยิ่งเมื่อเป็นแอปของคุณเองที่พังเพราะการเปลี่ยนแปลงที่ไม่เข้ากันย้อนหลังในเวอร์ชันหลักของ Rails ด้วยแล้ว นั่นคือช่วงเวลาที่เราต้องระลึกถึงคุณค่านี้ ว่าเรายกย่องความก้าวหน้าเหนือความมั่นคง เพื่อให้เรามีแรงฮึดในการแก้ไขสิ่งที่พัง หาให้เจอว่าเกิดอะไรขึ้น และก้าวให้ทันยุคสมัย
+นั่นไม่ได้เป็นใบอนุญาตให้ทำร้ายกันโดยไม่จำเป็นหรือทำเกินเหตุส่งเดชไปเรื่อยเปื่อย การย้ายครั้งใหญ่ของ Rails จาก 2.x ไป 3 ยังคงฝังอยู่ในรอยแผลเป็นของหลายคนที่อยู่ในเหตุการณ์นั้น มันเป็นเรื่องหนักหนาเป็นการปั่นป่วนครั้งใหญ่ที่ทิ้งผู้คนจำนวนมากไว้ข้างหลังในดินแดน 2.x อยู่นาน บางคนถึงกับเสียความรู้สึกจนยากจะเปลี่ยนใจ แต่เมื่อมองในภาพรวมแล้ว มันก็ยังคุ้มค่าอยู่ดี
+นั่นคือการแลกเปลี่ยนที่ยากลำบากซึ่งเราต้องทำต่อไป Rails จะอยู่ในสภาพที่ดีกว่าในอีกห้าปีข้างหน้าจากการเปลี่ยนแปลงที่เราทำวันนี้หรือไม่? Rails จะดีขึ้นไหมหากรับเอาโดเมนปัญหาอื่น ๆ เช่น การจัดคิวงานหรือ WebSocket มาใช้ในอนาคต? ถ้าใช่ ก็ฮึดสู้และลงมือทำกันเถอะ
+งานนี้ไม่ใช่เพียงสิ่งที่ต้องเกิดขึ้นในตัว Rails เองเท่านั้น แต่ยังรวมถึงในชุมชน Ruby ที่กว้างขึ้นด้วย Rails ควรอยู่แนวหน้าในการช่วยขับเคลื่อนความก้าวหน้าของ Ruby โดยกระตุ้นให้ผู้เกี่ยวข้องหันมาใช้เวอร์ชันที่ใหม่กว่าได้รวดเร็วขึ้น
+จนถึงตอนนี้เราทำได้ดีมาก ตั้งแต่ตอนที่ฉันเริ่มต้นมา เราขยับจาก Ruby 1.6, 1.8, 1.9, 2.0, 2.1, 2.2, 2.3, 2.4, 2.5 และตอนนี้ก็มาถึง 2.6 ระหว่างทางมีการเปลี่ยนแปลงครั้งใหญ่เยอะมาก แต่ Rails ก็อยู่ตรงนั้นคอยหนุนหลัง Ruby และช่วยให้ทุกคนตามโปรแกรมได้เร็วขึ้น นั่นเป็นทั้งสิทธิพิเศษและพันธะหน้าที่ส่วนหนึ่งที่ Rails มี ในฐานะผู้ผลักดันให้ Ruby เป็นที่นิยมอย่างกว้างขวาง
+สิ่งนี้ก็เป็นจริงกับเครื่องมือเสริมของเชนด้วยเช่นกัน ครั้งหนึ่ง Bundler เคยเป็นแนวคิดที่มีคนถกเถียงกันมาก แต่ด้วยความยืนกรานของ Rails ให้มันเป็นเสาหลักของอนาคตร่วมกัน ทุกวันนี้มันจึงเป็นสิ่งที่ถูกมองว่าเป็นเรื่องปกติไปแล้ว เช่นเดียวกันกับสิ่งต่าง ๆ อย่าง asset pipeline และ Spring ซึ่งเป็นกระบวนการคำสั่งแบบคงอยู่ ทั้งสามสิ่งนี้เคยผ่าน หรือยังคงกำลังผ่านช่วงเวลาปรับตัว เติบโตอยู่ แต่ความชัดเจนในคุณค่าระยะยาวของมันช่วยให้พวกเราฝ่าฟันสิ่งนั้นมาได้
+ความก้าวหน้าในท้ายที่สุดแล้วส่วนใหญ่ล้วนเกี่ยวกับผู้คนและความตั้งใจของพวกเขาที่จะผลักดันการเปลี่ยนแปลง นี่คือเหตุผลที่ไม่มีตำแหน่งตลอดชีพในกลุ่มอย่าง Rails Core หรือ Rails Committers. ทั้งสองกลุ่มเปิดกว้างสำหรับผู้ที่กำลังลงมือทำงานอย่างแข็งขันเพื่อขับเคลื่อนความก้าวหน้าของเฟรมเวิร์ก สำหรับบางคน การมีส่วนร่วมต่อความก้าวหน้าเช่นนี้อาจกินเวลาเพียงไม่กี่ปี และเราจะซาบซึ้งในบริการของพวกเขาเสมอ ส่วนสำหรับคนอื่นๆ ก็อาจยาวนานหลายทศวรรษ
+ในทำนองเดียวกัน นั่นจึงเป็นเหตุผลว่าทำไมมันถึงสำคัญมากที่เราจะต้องต้อนรับและสนับสนุนสมาชิกใหม่ของชุมชนอย่างต่อเนื่อง เราต้องการเลือดใหม่ และไอเดียสดใหม่เพื่อก้าวหน้าได้ดียิ่งขึ้น
+ด้วยความที่มีแนวคิดที่ขัดแย้งกันมากมายที่เกี่ยวข้อง Rails อาจจะกลายเป็นกลุ่มคนที่มีความคิดเป็นกลุ่มเล็ก ๆ และปิดตัวเองได้อย่างรวดเร็ว ถ้าเราต้องการให้ทุกคนแสดงความเคารพนับถือต่อทุกหลักการอย่างสมบูรณ์ตลอดเวลา แต่เราไม่ทำแบบนั้น!
+เราต้องการความไม่เห็นด้วย เราต้องการการอภิปราย เราต้องการความหลากหลายทางความคิดและคน นี่คือหม้อหลอมละลายของความคิดที่เราจะได้ส่วนร่วมที่ดีที่สุดให้ทุกคนแบ่งปัน มีคนมากมายมาช่วยเหลือด้วยการแสดงความคิดเห็นของตนเอง ไม่ว่าจะเป็นในรูปแบบของโค้ดหรือการโต้แย้งอย่างมีเหตุผล
+ดังนั้น แม้ว่าหลักการนี้จะอธิบายรูปแบบที่เป็นอุดมคติ แต่ความเป็นจริงในทุกวันกลับซับซ้อนกว่านั้นมาก (และน่าสนใจ) Rails สามารถรองรับชุมชนขนาดใหญ่ภายใต้ร่มเดียวกันได้เพราะมีการทดสอบความเชื่อที่น้อยมากหรือเกือบไม่มีเลย
+ความสำเร็จอย่างต่อเนื่องของ RSpec ซึ่งเป็น DSL สำหรับการทดสอบที่ผมมักจะแสดงความไม่พอใจอย่างรุนแรง ก็เป็นหลักฐานที่สมบูรณ์แบบ ผมสามารถวิจารณ์จนหน้าซีดว่าทำไมผมถึงไม่คิดว่ามันเป็นทางที่ดี และมันก็ยังคงเติบโตและเจริญรุ่งเรืองได้ จุดนี้ต่างหากที่สำคัญกว่ามาก!
+สิ่งเดียวกันนี้ก็จริงสำหรับการเกิดขึ้นของ Rails ในฐานะ API แม้ว่าความสนใจและความทุ่มเทส่วนตัวของผมจะอยู่ที่ระบบที่รวมทุกอย่างเข้าด้วยกันรวมถึงการแสดงผล แต่ก็ไม่ต้องสงสัยเลยว่า Rails มีพื้นที่สำหรับการทำงานได้ดีกับคนที่ต้องการแยกแยะไคลเอ็นต์และเซิร์ฟเวอร์ไว้ตั้งแต่แรก เราควรที่จะยอมรับสิ่งนี้เท่าที่มันสามารถอยู่ร่วมกันในฐานะภารกิจรองได้ และผมเชื่อว่ามันสามารถทำได้อย่างแน่นอน
+การมี "เต็นท์ใหญ่" ไม่ได้หมายความว่าจะพยายามเป็นทุกสิ่งทุกอย่างให้กับทุกคน มันแค่หมายความว่าคุณต้อนรับทุกคนมาที่งานเลี้ยงของคุณ และยอมให้พวกเขานำเครื่องดื่มของตัวเองมาด้วย เราไม่จำเป็นต้องสูญเสียจิตวิญญาณหรือคุณค่าของเราไปเพราะเชิญชวนให้คนอื่นมาร่วมกับเรา และเราอาจจะได้เรียนรู้วิธีผสมเครื่องดื่มใหม่ ๆ ที่อร่อยมากขึ้นอีกด้วย
+สิ่งนี้ไม่ได้มาโดยไม่มีค่าใช้จ่าย มันต้องการความพยายามในการต้อนรับ โดยเฉพาะอย่างยิ่งถ้าเป้าหมายของคุณไม่ใช่แค่การดึงดูดคนที่เหมือนกับคนที่อยู่ในชุมชนอยู่แล้ว การลดอุปสรรคในการเข้าถึงเป็นงานที่เราควรจะให้ความสำคัญอย่างจริงจังเสมอ
+คุณไม่มีทางรู้เลยว่าคนต่อไปที่เริ่มต้นจากการแก้ไขการสะกดผิดในเอกสารอาจจะเป็นคนที่พัฒนาฟีเจอร์สำคัญต่อไป แต่คุณมีโอกาสที่จะพบเจอถ้าคุณยิ้มและกล่าวขอบคุณสำหรับการมีส่วนร่วมเล็ก ๆ ที่กระตุ้นให้เกิดแรงจูงใจในการทำงาน
+