From f7f4a9213adb3ce5130b5ed806d956e358738106 Mon Sep 17 00:00:00 2001 From: zkan Date: Thu, 22 Aug 2024 18:30:53 +0700 Subject: [PATCH 1/7] Add th in language list --- doctrine/de.html | 3 + doctrine/es.html | 1 + doctrine/fr.html | 1 + doctrine/index.html | 1 + doctrine/ru.html | 1 + doctrine/th.html | 290 ++++++++++++++++++++++++++++++++++++++++++++ doctrine/zh_cn.html | 1 + doctrine/zh_tw.html | 1 + 8 files changed, 299 insertions(+) create mode 100644 doctrine/th.html diff --git a/doctrine/de.html b/doctrine/de.html index 0dab6b5a..e8618110 100644 --- a/doctrine/de.html +++ b/doctrine/de.html @@ -44,6 +44,9 @@

Die Rails-Doktrin.

  • Russian
    • +
  • + ไทย +
  • 简体中文
    • diff --git a/doctrine/es.html b/doctrine/es.html index 3fa34793..5ee6adef 100644 --- a/doctrine/es.html +++ b/doctrine/es.html @@ -27,6 +27,7 @@

    La Doctrina Rails.

  • English
  • Français
  • Russian
    • +
  • ไทย
  • 简体中文
  • 繁體中文
    • diff --git a/doctrine/fr.html b/doctrine/fr.html index ba2f11a3..5e7462ea 100644 --- a/doctrine/fr.html +++ b/doctrine/fr.html @@ -27,6 +27,7 @@

    La doctrine Rails.

  • Deutsch
  • Español
  • Russian
    • +
  • ไทย
  • 简体中文
  • 繁體中文
    • diff --git a/doctrine/index.html b/doctrine/index.html index e6a2f8d5..57c279ab 100644 --- a/doctrine/index.html +++ b/doctrine/index.html @@ -27,6 +27,7 @@

    The Rails Doctrine.

  • Español
  • Français
  • Russian
    • +
  • ไทย
  • 简体中文
  • 繁體中文
    • diff --git a/doctrine/ru.html b/doctrine/ru.html index e8be0057..73c4d3be 100644 --- a/doctrine/ru.html +++ b/doctrine/ru.html @@ -28,6 +28,7 @@

    Rails Соглашение

  • Deutsch
  • Español
  • Français
    • +
  • ไทย
  • 简体中文
  • 繁體中文
    • diff --git a/doctrine/th.html b/doctrine/th.html new file mode 100644 index 00000000..9d203375 --- /dev/null +++ b/doctrine/th.html @@ -0,0 +1,290 @@ +--- +title: The Rails Doctrine +permalink: /doctrine/th +redirect_from: + - /doctrine/th/ +--- + +
    +
    +
    +
    +

    The Rails Doctrine.

    +
    +
    +
    +
    David Heinemeier Hansson
    +
    +
    +
    + + +
    + +
    +
    +
    +
    +
    + +
    +
    +
    +
    +

    Ruby on Rails’ phenomenal rise to prominence owed much of its lift-off to novel technology and timing. But technological advantages erode over time, and good timing doesn’t sustain movements alone over the long term. So a broader explanation of how Rails has continued to not only stay relevant but to grow its impact and community is needed. I propose that the enduring enabler has been and remains its controversial doctrine.

    +

    This doctrine has evolved over the past decade, but most of its strongest pillars are also the founding ones. I make no claim to the fundamental originality of these ideas. The chief accomplishment of Rails was to unite and cultivate a strong tribe around a wide set of heretical thoughts about the nature of programming and programmers.

    +

    With all that ado, here follows the nine most important pillars of The Rails Doctrine, as perceived by yours truly:

    +
      +
    1. Optimize for programmer happiness
      2. +
    2. Convention over Configuration
      3. +
    3. The menu is omakase
      4. +
    4. No one paradigm
      5. +
    5. Exalt beautiful code
      6. +
    6. Provide sharp knives
      7. +
    7. Value integrated systems
      8. +
    8. Progress over stability
      9. +
    9. Push up a big tent
      10. +
    +
    +
    +
    +
    + +
    +
    +
    +
    +

    Optimize for programmer happiness

    +

    There would be no Rails without Ruby, so it’s only fitting that the first doctrinal pillar is lifted straight from the core motivation for creating Ruby.

    +

    Ruby’s original heresy was indeed to place the happiness of the programmer on a pedestal. Above many other competing and valid concerns that had driven programming languages and ecosystems before it.

    +

    Where Python might boast that there’s “one and preferably only one way to do something”, Ruby relished expressiveness and subtlety. Where Java championed forcefully protecting programmers from themselves, Ruby included a set of sharp knives in the welcome kit. Where Smalltalk drilled a purity of message passing, Ruby accumulated keywords and constructs with an almost gluttonous appetite.

    +

    Ruby was different because it valued different things. And most of those things were in service of this yearning for programmer happiness. A pursuit that brought it at odds with not only most other programming environments, but also the mainstream perception of what a programmer was and how they were supposed to act.

    +

    Ruby took to not only recognize but accommodate and elevate programmer feelings. Whether they be of inadequacy, whimsy, or joy. Matz jumped implementational hurdles of astounding complexity to make the machine appear to smile at and flatter its human co-conspirator. Ruby is full of optical illusions where that which seems simple, clear, and beautiful to our mind’s eye actually is an acrobatic mess of wires under the hood. These choices were not free (ask the JRuby crew about trying to reverse-engineer this magical music box!), which is precisely why they’re so commendable.

    +

    It was this dedication to an alternate vision for programming and programmers that sealed my love affair with Ruby. It wasn’t just ease of use, it wasn’t just aesthetics of blocks, it was no one single technical achievement. It was a vision. A counter culture. A place for the misfits of the existing professional programming mold to belong and associate with the like of mind.

    +

    I’ve described this discovery of Ruby in the past as finding a magical glove that just fit my brain perfectly. Better than I had ever imagined any glove could ever fit. But it was even more than that. It was the event that marked my own personal transition from ‘doing programming because I needed programs’ to ‘doing programming because I fell in love with it as a mode of intellectual exercise and expression’. It was finding a fountain of flow and being able to turn it on at will. For anyone familiar with Csikszentmihalyi’s work, the impact of this is hard to overstate.

    +

    I’m not exaggerating when I say that Ruby transformed me and set the course for my life’s work. So deep was the revelation. It imbued me with a calling to do missionary work in service of Matz’s creation. To help spread this profound creation and its benefits.

    +

    Now I can imagine most of you shaking your heads with incredulity. I don’t blame you. If someone had described the experience above to me when I was still living under the “programming is just a tool” paradigm, I too would have shook my head. And then I would probably have laughed at the over-the-top use of religious language. But for this to be a truthful account, it also has to be honest, even if that’s off-putting to some or even most.

    +

    Anyway, what did this mean for Rails and how does this principle continue to guide its evolution? To answer that, I think it’s instructive to look at another principle that was often used to describe Ruby in the early days: The Principle of Least Surprise. Ruby should behave how you’d expect it to. This is easily described with a contrast to 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 accepts both exit and quit to accommodate the programmer’s obvious desire to quit its interactive console. Python, on the other hand, pedantically instructs the programmer how to properly do what’s requested, even though it obviously knows what is meant (since it’s displaying the error message). That’s a pretty clear-cut, albeit small, example of PoLS.

    +

    The reason PoLS fell out of favor with the Ruby community was that this principle is inherently subjective. Least surprising to whom? Well, to Matz. And people who are surprised in the same way as him. As the Ruby community grew, and the ratio of people who were surprised by different things than Matz grew with it, this became a source of fruitless bike-shedding on the mailing lists. So the principle faded to the background, lest to invite more debates going nowhere over whether person X was surprised by behavior Y or not.

    +

    So again, what does this have to do with Rails? Well, Rails has been designed with a similar principle to Principle of Least Surprise (To Matz). The Principle of The Bigger Smile (of DHH), which is just what it says on the tin: APIs designed with great attention paid to whatever would make me smile more and broader. When I write it out like this, that sounds almost comically narcissistic, and even I find hard to argue against that first impression.

    +

    But creating something like Ruby or Rails is at least at its outset a deeply narcissistic endeavor. Both projects sprung from the mind of a singular creator. But perhaps I’m projecting my own motivations onto Matz here, so let me narrow the scope of my proclamation to that which I know: I created Rails for me. To make me smile, first and foremost. Its utility was to many degrees subservient to its ability to make me enjoy my life more. To enrich my daily toil of wrangling requirements and requests for web information systems.

    +

    Like Matz, I at times went to silly lengths to serve my principle. One example is the Inflector, a class that understands just enough of the patterns and irregularities of the English language to map a Person class to a People table, Analysis to Analyses, and simply Comment to Comments. This behavior is now accepted as an unquestioned element of Rails, but the fires of controversy raged with great intensity in the early days when we were still coalescing the doctrine and its importance.

    +

    Another example that required less implementation effort, but triggered almost as much consternation: Array#second through #fifth (and #forty_two for good trolling measure). These alias accessors were deeply offensive to a very vocal constituency who decried the bloat (and near end of civilization, for good measure) of something that could as well be written as Array#[1], Array#[2] (and Array[41]).

    +

    But both decisions still, to this day, make me smile. I relish getting to write people.third in a test case or the console. No, that’s not logical. It’s not efficient. It may even be pathological. But it continues to make me smile, thus fulfilling the principle and enriching my life, helping to justify my continued involvement with Rails after 12 years of service.

    +

    Unlike, say, optimizing for performance, it’s tough to measure optimizing for happiness. This makes it an almost inherently unscientific endeavor, which to some renders it less important, if not outright frustrating. Programmers are taught to argue and conquer the measurable. That which has clear conclusions and where A can categorically be shown to be better than B.

    +

    But while the pursuit of happiness is hard to measure at the micro level, it’s a lot clearer to observe at the macro level. The Ruby on Rails community is full of people who are here precisely because of this pursuit. They boast of better, more fulfilled working lives. It’s in this aggregate of emotions that the victory is clear.

    +

    So thus we conclude: Optimizing for happiness is perhaps the most formative key to Ruby on Rails. It shall remain such going forward.

    +
    +
    +
    +
    + +
    +
    +
    +
    +

    Convention over Configuration

    +

    One of the early productivity mottos of Rails went: “You’re not a beautiful and unique snowflake”. It postulated that by giving up vain individuality, you can leapfrog the toils of mundane decisions, and make faster progress in areas that really matter.

    +

    Who cares what format your database primary keys are described by? Does it really matter whether it’s “id”, “postId”, “posts_id”, or “pid”? Is this a decision that’s worthy of recurrent deliberation? No.

    +

    Part of the Rails’ mission is to swing its machete at the thick, and ever growing, jungle of recurring decisions that face developers creating information systems for the web. There are thousands of such decisions that just need to be made once, and if someone else can do it for you, all the better.

    +

    Not only does the transfer of configuration to convention free us from deliberation, it also provides a lush field to grow deeper abstractions. If we can depend on a Person class mapping to people table, we can use that same inflection to map an association declared as has_many :people to look for a Person class. The power of good conventions is that they pay dividends across a wide spectrum of use.

    +

    But beyond the productivity gains for experts, conventions also lower the barriers of entry for beginners. There are so many conventions in Rails that a beginner doesn’t even need to know about, but can just benefit from in ignorance. It’s possible to create great applications without knowing why everything is the way it is.

    +

    That’s not possible if your framework is merely a thick textbook and your new application a blank piece of paper. It takes immense effort to even figure out where and how to start. Half the battle of getting going is finding a thread to pull.

    +

    The same goes even when you understand how all the pieces go together. When there’s an obvious next step for every change, we can scoot through the many parts of an application that is the same or very similar to all the other applications that went before it. A place for everything and everything in its place. Constraints liberate even the most able minds.

    +

    As with anything, though, the power of convention isn’t without peril. When Rails makes it so trivial to do so much, it is easy to think every aspect of an application can be formed by precut templates. But most applications worth building have some elements that are unique in some way. It may only be 5% or 1%, but it’s there.

    +

    The hard part is knowing when to stray from convention. When are the deviating particulars grave enough to warrant an excursion? I contend that most impulses to be a beautiful and unique snowflake are ill considered, and that the cost of going off the Rails is under appreciated, but just enough of them won’t be that you need to examine all of them carefully.

    +
    +
    +
    +
    + +
    +
    +
    +
    +

    The menu is omakase

    +

    How do you know what to order in a restaurant when you don’t know what’s good? Well, if you let the chef choose, you can probably assume a good meal, even before you know what “good” is. That is omakase. A way to eat well that requires you neither be an expert in the cuisine nor blessed with blind luck at picking in the dark. +

    For programming, the benefits of this practice, letting others assemble your stack, is similar to those we derive from Convention over Configuration, but at a higher level. Where CoC is occupied with how we best use individual frameworks, omakase is concerned with which frameworks, and how they fit together. +

    This is at odds with the revered programming tradition of presenting available tools as individual choices, and to bestow the individual programmer privilege (and burden!) of deciding. +

    You’ve surely heard, and probably nodded to, “use the best tool for the job”. It sounds so elementary as to be beyond debate, but being able to pick the “best tool” depends on a foundation that allows “best” to be determined with confidence. This is much harder than it seems. +

    It is a problem similar to that of the diner in a restaurant. And like picking each course in an eight-set meal, picking each individual library or framework is not a job done in isolation. The objective in both cases is to consider the whole evening or system. +

    So with Rails we decided to diminish one good, a programmer’s individual privilege to choose each tool in their box, for a greater one: A better tool box for all. The dividends are legion: +

      +
    1. There’s safety in numbers: When most people are using Rails in the same default ways, we have a shared experience. This common ground makes it much easier to teach and help people. It lays a foundation for debate on approach. We all watched the same show last night at 7, so we can talk about it the next day. It fosters a stronger sense of community.
      2. +
    2. People are perfecting the same, basic tool box: As a full-stack framework, Rails has a lot of moving parts, and how those work together is as important as what they do in isolation. Much of the pain in software comes not from the individual components, but from their interaction. When we all work on alleviating shared pain from components that are configured and fail in the same ways, then we all experience less pain.
      3. +
    3. Substitutions are still possible, but not required: While Rails is an omakase stack, it still allows you to replace certain frameworks or libraries with alternatives. It just doesn’t require you to. Which means you can delay those decisions until you’ve developed a clear, personal palate that may prefer the occasional difference.
      4. +
    +

    Because even the most learned and skilled programmers who come to and stay in Rails aren’t likely opposed to all matters of the menu. (If they were, they probably wouldn’t have stuck with Rails.) So they pick their substitutions with diligence, and then go on to enjoy the rest of the curated, shared stack alongside everyone else.

    +
    +
    +
    +
    + +
    +
    +
    +
    +

    No one paradigm

    +

    There’s a strong emotional appeal to picking a single central idea and following it to the logical conclusion as your architectural underpinning. There’s a purity in such discipline, so it’s clear why programmers are naturally attracted to this bright light.

    +

    Rails isn’t like that. It isn’t a single, perfect cut of cloth. It’s a quilt. A composite of many different ideas and even paradigms. Many that would usually be seen in conflict, if contrasted alone and one by one. But that’s not what we’re trying to do. It isn’t a single championship of superior ideas where a sole winner must be declared.

    +

    Take the templates we build the view in our Rails MVC pie with. By default, all the helpers that allow us to extract code from these templates are just a big pot of functions! It’s a single namespace even. Oh the shock and the horror, it’s like PHP soup!

    +

    But I contend that PHP had it right when it came to presenting individual functions that rarely needed to interact, as is the case with much abstraction in view templates. And for this purpose, the single namespace, the big pot of methods, is not only a reasonable choice, but a great one.

    +

    This doesn’t mean we don’t occasionally want to reach for something more object-oriented when building views. The concept of Presenters, where we wrap many methods that are interdependent with each other and the data below it, can occasionally be the perfect antidote to a soup of methods turned sour by dependencies. But it’s generally proved to be the rare rather than common fit.

    +

    In comparison, we generally treat the model in our MVC layer cake as the prime bastion of object-oriented goodness. Finding just the right names for objects, increasing the coherence, and lowering the coupling is the fun of domain modeling. It’s a very different layer from the view, so we take a different approach.

    +

    But even here we don’t subscribe to single-paradigm dogma. Rails concerns, the specialization of Ruby’s mixins, are often used to give the individual models a very wide surface area. This fits well with the Active Record pattern by giving the concerned methods direct access to the data and storage they interact with.

    +

    Even the very foundation of the Active Record framework offends some purists. We’re mixing the logic needed for interfacing with the database directly with the business domain and logic. Such conflation of boundaries! Yes, because it proved to be the practical way to skin a web-app cat that virtually always talks to a database of some sort to persist the state of the domain model.

    +

    To be so ideologically flexible is what enables Rails to tackle such a wide array of problems. Most individual paradigms do very well within a certain slice of the problem space, but become awkward or rigid when applied beyond its natural sphere of comfort. By applying many overlapping paradigms, we cover the flanks and guard the rear. The final framework is far stronger and more capable than any individual paradigm would have allowed it to be.

    +

    Now, the cost of this polyamorous relationship with the many paradigms of programming is conceptual overhead. It’s not enough to just know object-oriented programming to have a good time with Rails. It’s preferable to be well served with procedural and functional experiences as well.

    +

    This applies to the many sub-languages of Rails as well. We don’t try to shield you that much from having to learn, say, JavaScript for the view or SQL for the occasional complicated query. At least not to reach the peaks of possibilities.

    +

    The way to alleviate some of that learning burden is to simply just make it easy to get started, make something of real value, before you understand every single aspect of the framework. We have a rush to Hello World for this reason. Your table already prepared and an appetizer served.

    +

    The thinking is that by giving something of real value early, we’ll encourage the practitioners of Rails to level-up quickly. Accept their journey of learning as a joy, not an obstacle.

    +
    +
    +
    +
    + +
    +
    +
    +
    +

    Exalt beautiful code

    +

    We write code not just to be understood by the computer or other programmers, but to bask in the warm glow of beauty. Aesthetically pleasing code is a value unto itself and should be pursued with vigor. That doesn’t mean that beautiful code always trumps other concerns, but it should have a full seat at the table of priorities.

    +

    So what is beautiful code? In Ruby, it’s often somewhere at the intersection between native Ruby idioms and the power of a custom domain-specific language. It’s a fuzzy line, but one well worth trying to dance.

    +

    Here’s a simple example from Active Record:

    +{% highlight ruby %} +class Project < ApplicationRecord + belongs_to :account + has_many :participants, class_name: 'Person' + validates_presence_of :name +end +{% endhighlight %} +

    This looks like DSL, but it’s really just a class definition with three class-method calls that take symbols and options. There’s nothing fancy here. But it sure is pretty. It sure is simple. It gives an immense amount of power and flexibility from those few declarations.

    +

    Part of the beauty comes from these calls honoring the previous principles, like Convention over Configuration. When we call belongs_to :account, we’re assuming that the foreign key is called account_id and that it lives in the projects table. When we have to designate the class_name of Person to the role of the participants association, we require just that class name definition. From it we’ll derive, again, the foreign keys and other configuration points.

    +

    Here’s another example from the database migrations system:

    +{% highlight ruby %} +class CreateAccounts < ActiveRecord::Migration + def change + create_table :accounts do |t| + t.integer :queenbee_id + t.timestamps + end + end +end +{% endhighlight %} +

    This is the essence of framework power. The programmer declares a class according to certain convention, like a ActiveRecord::Migration subclass that implements #change, and the framework can do all the plumbing that goes around that, and know this is the method to call.

    +

    This leaves the programmer with very little code to write. In the case of migrations, not only will this allow a call to rails db:migrate to upgrade the database to add this new table, it’ll also allow it to go the other way of dropping this table with another call. This is very different from a programmer making all this happen and stitching the workflow together from libraries they call themselves.

    +

    Sometimes beautiful code is more subtle, though. It’s less about making something as short or powerful as possible, but more about making the rhythm of the declaration flow.

    +

    These two statements do the same:

    +{% highlight ruby %} +if people.include? person +... +if person.in? people +{% endhighlight %} +

    But the flow and focus is subtly different. In the first statement, the focus is on the collection. That’s our subject. In the second statement, the subject is clearly the person. There’s not much between the two statements in length, but I’ll contend that the second is far more beautiful and likely to make me smile when used in a spot where the condition is about the person.

    +
    +
    +
    +
    + +
    +
    +
    +
    +

    Provide sharp knives

    +

    Ruby includes a lot of sharp knives in its drawer of features. Not by accident, but by design. The most famous is monkey patching: The power to change existing classes and methods.

    +

    This power has frequently been derided as simply too much for mere mortal programmers to handle. People from more restrictive environments used to imagine all sorts of calamities that would doom Ruby because of the immense trust the language showed its speakers with this feature.

    +

    If you can change anything, what is there to stop you from overwriting String#capitalize so that “something bold”.capitalize returns “Something Bold” rather than “Something bold”? That might work in your local application, but then break all sorts of auxiliary code that depend on the original implementation.

    +

    Nothing, is the answer. There’s nothing programmatically in Ruby to stop you using its sharp knives to cut ties with reason. We enforce such good senses by convention, by nudges, and through education. Not by banning sharp knives from the kitchen and insisting everyone use spoons to slice tomatoes.

    +

    Because the flip side of monkey patching is the power to do such feats of wonder as 2.days.ago (which returns a date two days back from the current). Now you might well think that’s a bad trade. That you’d rather lose 2.days.ago if it means preventing programmers from overwriting String#capitalize. If that’s your position, Ruby is probably not for you.

    +

    Yet it’d be hard — even for people who would give up such freedom for some security — to argue that the power to change core classes and methods has doomed Ruby as a language. On the contrary, the language flourished exactly because it offered a different and radical perspective on the role of the programmer: That they could be trusted with sharp knives.

    +

    And not only trusted, but taught in the ways to use such capable tools. That we could elevate the entire profession by assuming most programmers would want to become better programmers, capable of wielding sharp knives without cutting off their fingers. That’s an incredibly aspirational idea, and one that runs counter to a lot of programmer’s intuition about other programmers.

    +

    Because it’s always about other programmers when the value of sharp knives is contested. I’ve yet to hear a single programmer put up their hand and say “I can’t trust myself with this power, please take it away from me!”. It’s always “I think other programmers would abuse this”. That line of paternalism has never appealed to me.

    +

    That brings us to Rails. The knives provided by the framework are not nearly as sharp as those offered with the language, but some are still plenty keen to cut. We will make no apologies for offering such tools as part of the kit. In fact, we should celebrate having enough faith in the aspirations of our fellow programmers to dare trust them.

    +

    Plenty of features in Rails have been contested over time as being “too much freedom”. But one example that’s currently in vogue is the feature of concerns. This is a thin layer of syntactic sugar around Ruby’s built-in feature of modules and is designed to allow a single class to encapsulate multiple related but independently understood concerns (hence the name).

    +

    The charge is that concerns provide programmers prone to bloat their objects with a whole new set of drawers to stuff their clutter in. And that’s true. Concerns can indeed be used like that.

    +

    But the grand fallacy is thinking that by not providing a feature like concerns, which when used by even mildly capable hands allows an eloquent partial separation of concepts, we’d put programmers on the path to architectural bliss. If you can’t be trusted to keep the kitchen sink out of your overstuffed concerns, you’re probably not going to end up with a shining beacon of elegance otherwise.

    +

    Programmers who haven’t learned to wield sharp knives just aren’t going to make meringues yet. Operative word here: Yet. I believe that every programmer has a path, if not a right, to become fully capable Ruby and Rails programmers. And by capable, I mean knowledgeable enough to know when and how, accordingly to their context, they should use the different and sometimes dangerous tools in the drawers.

    +

    That does not abdicate a responsibility to help get them there. The language and the framework should be patient tutors willing to help and guide anyone to experthood. While recognizing that the only reliable course there goes through the land of mistakes: Tools used wrong, a bit of blood, sweat, and perhaps even some tears. There simply is no other way.

    +

    Ruby on Rails is an environment for chefs and those who wish to become chefs. You might start out doing the dishes, but you can work your way up to running the kitchen. Don’t let anyone tell you that you can’t be trusted with the best tool in the trade as part of that journey.

    +
    +
    +
    +
    + +
    +
    +
    +
    +

    Value integrated systems

    +

    Rails can be used in many contexts, but its first love is the making of integrated systems: Majestic monoliths! A whole system that addresses an entire problem. This means Rails is concerned with everything from the front-end JavaScript needed to make live updates to how the database is migrated from one version to another in production.

    +

    That’s a very broad scope, as we’ve discussed, but no broader than to be realistic to understand for a single person. Rails specifically seeks to equip generalist individuals to make these full systems. Its purpose is not to segregate specialists into small niches and then require whole teams of such in order to build anything of enduring value.

    +

    It is this focus on empowering the individual that points to the integrated system. It’s in the integrated system we can cut out many needless abstractions, reduce the duplication between layers (like templates on both the server and the client), and, above all, avoid distributing our system before we absolutely, positively have to.

    +

    Much of the complication in systems development comes from introducing new boundaries between the elements that restrict how you make calls between A and B. Method calls between objects is far simpler than remote procedure calls between microservices. There’s a whole new world of hurt in failure states, latency issues, and dependency update schedules that await those who venture into the lair of distribution.

    +

    Sometimes this distribution is simply necessary. If you want to create an API to your web application that other people can call over HTTP, well, then you just have to suck it up and deal with many of these issues (although handling requests inbound rather than sending them outbound is much easier – your downtime is someone else’s failure state!). But that’s at least a limited amount of damage inflicted on your own personal development experience.

    +

    What’s worse is when systems are prematurely disintegrated and broken into services or, even worse, microservices. This drive frequently starts from the misconception that if you want a Modern Internet Application, you’ll simply have to build the systems many times over: Once on the server side, once on the JavaScript MVC client-side, once for each of the native mobile applications, and so forth. This is not a law of nature, it needn’t be so.

    +

    It’s entirely possible to share large chunks of the entire application across multiple apps and accesses. To use the same controllers and views for the desktop web as for embedded in native mobile apps. To centralize as much as possible within that glorious, majestic monolith: The integrated system.

    +

    All this without giving up much if anything in terms of speed, user experience, or other attributes that falsely draw developers to premature distribution.

    +

    That’s the have-most-of-it-all we seek: All the power of individually tuned and distributed applications with the ease-of-use and understanding of a single, integrated system.

    +
    +
    +
    +
    + +
    +
    +
    +
    +

    Progress over stability

    +

    When systems have been around for more than a decade, like Rails has, their natural tendency is towards ossification. There are a million reasons why every change might be an issue for someone, somewhere who depended on past behavior. And fair reasons those are too, for the individual.

    +

    But if we listen too closely to the voices of conservatism, we’ll never see what’s on the other side. We have to dare occasionally break and change how things are to evolve and grow. It is this evolution that’ll keep Rails fit for survival and prosperity in the decade(s?) to come.

    +

    This is all easy to understand in theory, but much harder to swallow in practice. Especially when it’s your application that breaks from a backwards-incompatible change in a major version of Rails. It’s at those times we need to remember this value, that we cherish progress over stability, to give us the strength to debug the busted, figure it out, and move with the times.

    +

    That’s not a license to inflict needless or excessive hurt willy nilly. The Great Rails Migration of 2.x to 3 still lingers in the scar tissue of many who were around for that. It was a tough one. A serious upheaval that left many behind in 2.x land for a long time, some soured beyond convincing. But, in the grand scheme of things, it was still worth it.

    +

    Those are the hard bargains we have to continue to make. Is Rails going to be better off in five years for the changes we make today? Is Rails going to be better off for adopting another problem domain, like job queuing or WebSockets, in years to come? If yes, then let’s suck it up and do the work.

    +

    This work isn’t just something that needs to happen in Rails itself, but also in the larger Ruby community. Rails should be at the frontier of helping Ruby’s progress by driving its constituents to adopt later versions faster.

    +

    We’ve done very well at this so far. From when I started, we’ve moved through Ruby 1.6, 1.8, 1.9, 2.0, 2.1, 2.2, 2.3, 2.4, 2.5 and now onto 2.6. Lots of major changes along the way, but Rails was there to have Ruby’s back, and help everyone get with the program faster. That’s in part the privilege and obligation Rails serves as the major popularizer of Ruby.

    +

    This too is true for the auxiliary tools of the chain. Bundler was once a controversial idea, but through Rails’ insistence that it be a cornerstone of a shared future, it’s today just taken for granted. The same is true for things like the asset pipeline and Spring, the persistent command process. All three of these went through, or are still going through, growing pains, but the obviousness of their value in the long term helped us push through that.

    +

    Progress is ultimately mostly about people and their willingness to push change. This is why there are no lifetime seats in groups like Rails Core or Rails Committers. Both groups are for those who are actively working on making progress for the framework. For some, their stake in such progress may last just a few years, and we will forever be grateful for their service, and for others it may last decades.

    +

    Likewise, it’s why it’s so important for us to continue to welcome and encourage new members of the community. We need fresh blood and fresh ideas to make better progress.

    +
    +
    +
    +
    + +
    +
    +
    +
    +

    Push up a big tent

    +

    With so many controversial ideas to its credit, Rails could quickly become an insular group of ideological hermits, if we required everyone to exhibit complete deference to all tenets, all the time. So we don’t!

    +

    We need disagreement. We need dialects. We need diversity of thought and people. It’s in this melting pot of ideas we’ll get the best commons for all to share. Lots of people chipping in their two cents, in code or considered argument.

    +

    So while this doctrine has described an idealized form, the everyday reality is much more nuanced (and interesting). Rails is capable of supporting such a large community under one tent exactly because there are so few if any litmus tests.

    +

    The continued success of RSpec, a DSL for testing I’ve often expressed grave discontent with, is perfect proof. I can rant until I’m blue in the face of why I don’t think it’s the way to go, and it can still blossom and prosper. That point is the far more important one!

    +

    The same is true for the advent of Rails as an API. While my personal focus and dedication is to the integrated system that includes the view, there’s undoubtedly room for Rails to do well with people who do want to distribute their clients and servers upfront. We should embrace this inasmuch as it can coexist as a secondary mission, and I believe it surely can.

    +

    Having a big tent doesn’t mean trying to be all things to all people, though. It just means you welcome all people to your party, and allow them to bring their own drinks. We need to lose none of our soul or values by offering others to join us, and we may well learn how to mix a new delicious drink or two.

    +

    This doesn’t come for free. It requires work to be welcoming. Especially if your goal isn’t just to attract more people who are just like the ones who are already part of the community. Lowering the barriers to entry is work we should always take seriously.

    +

    You never know when the next person who starts just fixing a misspelling in the documentation ends up implementing the next great feature. But you stand a chance to find out if you smile and say thank you for whatever small contribution that gets the motivation flowing.

    +
    +
    +
    +
    diff --git a/doctrine/zh_cn.html b/doctrine/zh_cn.html index 0d515920..44f8c1ab 100644 --- a/doctrine/zh_cn.html +++ b/doctrine/zh_cn.html @@ -28,6 +28,7 @@

    Rails 信条

  • Español
  • Français
  • Russian
    • +
  • ไทย
  • 繁體中文
    • diff --git a/doctrine/zh_tw.html b/doctrine/zh_tw.html index 78d359e5..571ee5dc 100644 --- a/doctrine/zh_tw.html +++ b/doctrine/zh_tw.html @@ -29,6 +29,7 @@

    Rails 基本主義

  • Español
  • Français
  • Russian
    • +
  • ไทย
  • 简体中文
    • From 1a3e90bd7801b9655838939e4a54f20efcfaa4b2 Mon Sep 17 00:00:00 2001 From: zkan Date: Tue, 27 Aug 2024 20:05:01 +0700 Subject: [PATCH 2/7] Translate abstract and table of content --- doctrine/th.html | 53 ++++++++++++++++++++++++++++-------------------- 1 file changed, 31 insertions(+), 22 deletions(-) diff --git a/doctrine/th.html b/doctrine/th.html index 9d203375..d7ec1cad 100644 --- a/doctrine/th.html +++ b/doctrine/th.html @@ -9,7 +9,7 @@
    -

    The Rails Doctrine.

    +

    หลักการของ Rails

    @@ -41,19 +41,28 @@

    The Rails Doctrine.

    -

    Ruby on Rails’ phenomenal rise to prominence owed much of its lift-off to novel technology and timing. But technological advantages erode over time, and good timing doesn’t sustain movements alone over the long term. So a broader explanation of how Rails has continued to not only stay relevant but to grow its impact and community is needed. I propose that the enduring enabler has been and remains its controversial doctrine.

    -

    This doctrine has evolved over the past decade, but most of its strongest pillars are also the founding ones. I make no claim to the fundamental originality of these ideas. The chief accomplishment of Rails was to unite and cultivate a strong tribe around a wide set of heretical thoughts about the nature of programming and programmers.

    -

    With all that ado, here follows the nine most important pillars of The Rails Doctrine, as perceived by yours truly:

    +

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

    +

    + หลักการนี้ได้พัฒนาไปในช่วงทศวรรษที่ผ่านมา แต่เสาหลักส่วนใหญ่ของมันก็ยังคงเป็นเสาหลักดั้งเดิม + ฉันไม่ได้อ้างว่าความคิดเหล่านี้เป็นของใหม่อย่างแท้จริง ความสำเร็จหลักของ Rails คือการรวมตัวและสร้างชุมชนที่แข็งแกร่งรอบ ๆ + ความคิดที่ท้าทายเกี่ยวกับธรรมชาติของการเขียนโปรแกรมและโปรแกรมเมอร์ +

    +

    และต่อไปนี้คือเสาหลักทั้งเก้าที่สำคัญที่สุดของหลักการ Rails ตามความเห็นของฉันเอง

      -
    1. Optimize for programmer happiness
      2. -
    2. Convention over Configuration
      3. -
    3. The menu is omakase
      4. -
    4. No one paradigm
      5. -
    5. Exalt beautiful code
      6. -
    6. Provide sharp knives
      7. -
    7. Value integrated systems
      8. -
    8. Progress over stability
      9. -
    9. Push up a big tent
      10. +
    10. เพิ่มประสิทธิภาพเพื่อความสุขของโปรแกรมเมอร์
      11. +
    11. การตั้งค่ามาตรฐานเหนือการกำหนดค่า
      12. +
    12. เมนูเป็นแบบโอมะกะเสะ
      13. +
    13. ไม่มีแนวคิดเดียวที่ครอบคลุมทั้งหมด
      14. +
    14. ยกย่องโค้ดที่สวยงาม
      15. +
    15. จัดเตรียมเครื่องมือที่คม
      16. +
    16. ให้คุณค่ากับระบบที่บูรณาการ
      17. +
    17. ความก้าวหน้าสำคัญกว่าความเสถียร
      18. +
    18. ยอมรับความหลากหลาย
    @@ -64,7 +73,7 @@

    The Rails Doctrine.

    -

    Optimize for programmer happiness

    +

    เพิ่มประสิทธิภาพเพื่อความสุขของโปรแกรมเมอร์

    There would be no Rails without Ruby, so it’s only fitting that the first doctrinal pillar is lifted straight from the core motivation for creating Ruby.

    Ruby’s original heresy was indeed to place the happiness of the programmer on a pedestal. Above many other competing and valid concerns that had driven programming languages and ecosystems before it.

    Where Python might boast that there’s “one and preferably only one way to do something”, Ruby relished expressiveness and subtlety. Where Java championed forcefully protecting programmers from themselves, Ruby included a set of sharp knives in the welcome kit. Where Smalltalk drilled a purity of message passing, Ruby accumulated keywords and constructs with an almost gluttonous appetite.

    @@ -104,7 +113,7 @@

    Optimize for programmer happiness

    -

    Convention over Configuration

    +

    การตั้งค่ามาตรฐานเหนือการกำหนดค่า

    One of the early productivity mottos of Rails went: “You’re not a beautiful and unique snowflake”. It postulated that by giving up vain individuality, you can leapfrog the toils of mundane decisions, and make faster progress in areas that really matter.

    Who cares what format your database primary keys are described by? Does it really matter whether it’s “id”, “postId”, “posts_id”, or “pid”? Is this a decision that’s worthy of recurrent deliberation? No.

    Part of the Rails’ mission is to swing its machete at the thick, and ever growing, jungle of recurring decisions that face developers creating information systems for the web. There are thousands of such decisions that just need to be made once, and if someone else can do it for you, all the better.

    @@ -123,7 +132,7 @@

    Convention over Configuration

    -

    The menu is omakase

    +

    เมนูเป็นแบบโอมะกะเสะ

    How do you know what to order in a restaurant when you don’t know what’s good? Well, if you let the chef choose, you can probably assume a good meal, even before you know what “good” is. That is omakase. A way to eat well that requires you neither be an expert in the cuisine nor blessed with blind luck at picking in the dark.

    For programming, the benefits of this practice, letting others assemble your stack, is similar to those we derive from Convention over Configuration, but at a higher level. Where CoC is occupied with how we best use individual frameworks, omakase is concerned with which frameworks, and how they fit together.

    This is at odds with the revered programming tradition of presenting available tools as individual choices, and to bestow the individual programmer privilege (and burden!) of deciding. @@ -145,7 +154,7 @@

    The menu is omakase

    -

    No one paradigm

    +

    ไม่มีแนวคิดเดียวที่ครอบคลุมทั้งหมด

    There’s a strong emotional appeal to picking a single central idea and following it to the logical conclusion as your architectural underpinning. There’s a purity in such discipline, so it’s clear why programmers are naturally attracted to this bright light.

    Rails isn’t like that. It isn’t a single, perfect cut of cloth. It’s a quilt. A composite of many different ideas and even paradigms. Many that would usually be seen in conflict, if contrasted alone and one by one. But that’s not what we’re trying to do. It isn’t a single championship of superior ideas where a sole winner must be declared.

    Take the templates we build the view in our Rails MVC pie with. By default, all the helpers that allow us to extract code from these templates are just a big pot of functions! It’s a single namespace even. Oh the shock and the horror, it’s like PHP soup!

    @@ -168,7 +177,7 @@

    No one paradigm

    -

    Exalt beautiful code

    +

    ยกย่องโค้ดที่สวยงาม

    We write code not just to be understood by the computer or other programmers, but to bask in the warm glow of beauty. Aesthetically pleasing code is a value unto itself and should be pursued with vigor. That doesn’t mean that beautiful code always trumps other concerns, but it should have a full seat at the table of priorities.

    So what is beautiful code? In Ruby, it’s often somewhere at the intersection between native Ruby idioms and the power of a custom domain-specific language. It’s a fuzzy line, but one well worth trying to dance.

    Here’s a simple example from Active Record:

    @@ -211,7 +220,7 @@

    Exalt beautiful code

    -

    Provide sharp knives

    +

    จัดเตรียมเครื่องมือที่คม

    Ruby includes a lot of sharp knives in its drawer of features. Not by accident, but by design. The most famous is monkey patching: The power to change existing classes and methods.

    This power has frequently been derided as simply too much for mere mortal programmers to handle. People from more restrictive environments used to imagine all sorts of calamities that would doom Ruby because of the immense trust the language showed its speakers with this feature.

    If you can change anything, what is there to stop you from overwriting String#capitalize so that “something bold”.capitalize returns “Something Bold” rather than “Something bold”? That might work in your local application, but then break all sorts of auxiliary code that depend on the original implementation.

    @@ -236,7 +245,7 @@

    Provide sharp knives

    -

    Value integrated systems

    +

    ให้คุณค่ากับระบบที่บูรณาการ

    Rails can be used in many contexts, but its first love is the making of integrated systems: Majestic monoliths! A whole system that addresses an entire problem. This means Rails is concerned with everything from the front-end JavaScript needed to make live updates to how the database is migrated from one version to another in production.

    That’s a very broad scope, as we’ve discussed, but no broader than to be realistic to understand for a single person. Rails specifically seeks to equip generalist individuals to make these full systems. Its purpose is not to segregate specialists into small niches and then require whole teams of such in order to build anything of enduring value.

    It is this focus on empowering the individual that points to the integrated system. It’s in the integrated system we can cut out many needless abstractions, reduce the duplication between layers (like templates on both the server and the client), and, above all, avoid distributing our system before we absolutely, positively have to.

    @@ -255,7 +264,7 @@

    Value integrated systems

    -

    Progress over stability

    +

    ความก้าวหน้าสำคัญกว่าความเสถียร

    When systems have been around for more than a decade, like Rails has, their natural tendency is towards ossification. There are a million reasons why every change might be an issue for someone, somewhere who depended on past behavior. And fair reasons those are too, for the individual.

    But if we listen too closely to the voices of conservatism, we’ll never see what’s on the other side. We have to dare occasionally break and change how things are to evolve and grow. It is this evolution that’ll keep Rails fit for survival and prosperity in the decade(s?) to come.

    This is all easy to understand in theory, but much harder to swallow in practice. Especially when it’s your application that breaks from a backwards-incompatible change in a major version of Rails. It’s at those times we need to remember this value, that we cherish progress over stability, to give us the strength to debug the busted, figure it out, and move with the times.

    @@ -275,7 +284,7 @@

    Progress over stability

    -

    Push up a big tent

    +

    ยอมรับความหลากหลาย

    With so many controversial ideas to its credit, Rails could quickly become an insular group of ideological hermits, if we required everyone to exhibit complete deference to all tenets, all the time. So we don’t!

    We need disagreement. We need dialects. We need diversity of thought and people. It’s in this melting pot of ideas we’ll get the best commons for all to share. Lots of people chipping in their two cents, in code or considered argument.

    So while this doctrine has described an idealized form, the everyday reality is much more nuanced (and interesting). Rails is capable of supporting such a large community under one tent exactly because there are so few if any litmus tests.

    From c91c9024871bd29edd3dc9acc568e586e97a4d24 Mon Sep 17 00:00:00 2001 From: zkan Date: Tue, 27 Aug 2024 20:28:54 +0700 Subject: [PATCH 3/7] Translate convention over configuration --- doctrine/th.html | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/doctrine/th.html b/doctrine/th.html index d7ec1cad..32cca7d6 100644 --- a/doctrine/th.html +++ b/doctrine/th.html @@ -114,15 +114,15 @@

    เพิ่มประสิทธิภาพเพื่อความ

    การตั้งค่ามาตรฐานเหนือการกำหนดค่า

    -

    One of the early productivity mottos of Rails went: “You’re not a beautiful and unique snowflake”. It postulated that by giving up vain individuality, you can leapfrog the toils of mundane decisions, and make faster progress in areas that really matter.

    -

    Who cares what format your database primary keys are described by? Does it really matter whether it’s “id”, “postId”, “posts_id”, or “pid”? Is this a decision that’s worthy of recurrent deliberation? No.

    -

    Part of the Rails’ mission is to swing its machete at the thick, and ever growing, jungle of recurring decisions that face developers creating information systems for the web. There are thousands of such decisions that just need to be made once, and if someone else can do it for you, all the better.

    -

    Not only does the transfer of configuration to convention free us from deliberation, it also provides a lush field to grow deeper abstractions. If we can depend on a Person class mapping to people table, we can use that same inflection to map an association declared as has_many :people to look for a Person class. The power of good conventions is that they pay dividends across a wide spectrum of use.

    -

    But beyond the productivity gains for experts, conventions also lower the barriers of entry for beginners. There are so many conventions in Rails that a beginner doesn’t even need to know about, but can just benefit from in ignorance. It’s possible to create great applications without knowing why everything is the way it is.

    -

    That’s not possible if your framework is merely a thick textbook and your new application a blank piece of paper. It takes immense effort to even figure out where and how to start. Half the battle of getting going is finding a thread to pull.

    -

    The same goes even when you understand how all the pieces go together. When there’s an obvious next step for every change, we can scoot through the many parts of an application that is the same or very similar to all the other applications that went before it. A place for everything and everything in its place. Constraints liberate even the most able minds.

    -

    As with anything, though, the power of convention isn’t without peril. When Rails makes it so trivial to do so much, it is easy to think every aspect of an application can be formed by precut templates. But most applications worth building have some elements that are unique in some way. It may only be 5% or 1%, but it’s there.

    -

    The hard part is knowing when to stray from convention. When are the deviating particulars grave enough to warrant an excursion? I contend that most impulses to be a beautiful and unique snowflake are ill considered, and that the cost of going off the Rails is under appreciated, but just enough of them won’t be that you need to examine all of them carefully.

    +

    หนึ่งในสโลแกนด้านการเพิ่มผลิตภาพของ Rails ในช่วงแรกกล่าวว่า: “คุณไม่ใช่หิมะเกล็ดสวยงามและเป็นเอกลักษณ์” มันเสนอว่า การละทิ้งความเป็นเอกลักษณ์ที่ไม่มีประโยชน์นั้นจะช่วยให้คุณข้ามผ่านความยุ่งยากของการตัดสินใจที่ซ้ำซาก และทำให้ก้าวหน้าได้เร็วขึ้นในพื้นที่ที่สำคัญจริง ๆ

    +

    ใครจะสนใจว่าคีย์หลักของฐานข้อมูลของคุณถูกอธิบายด้วยรูปแบบใด? มันสำคัญจริงหรือว่ามันจะเป็น “id”, “postId”, “posts_id”, หรือ “pid”? นี่คือการตัดสินใจที่ควรพิจารณาซ้ำไปซ้ำมาไหม? ไม่

    +

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

    +

    การเปลี่ยนแปลงจากการกำหนดค่าเป็นการตั้งค่ามาตรฐานไม่เพียงแต่ทำให้เราหลีกเลี่ยงการพิจารณาซ้ำซาก ยังเปิดโอกาสให้เราสามารถสร้างนามธรรมที่ลึกซึ้งยิ่งขึ้น หากเราสามารถพึ่งพาคลาส Person ที่จับคู่กับตาราง people เราสามารถใช้การเปลี่ยนแปลงเดียวกันนี้เพื่อจับคู่การเชื่อมโยงที่ประกาศว่า has_many :people เพื่อมองหาคลาส Person พลังของการตั้งค่ามาตรฐานที่ดี จะให้ผลตอบแทนที่หลากหลาย

    +

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

    +

    สิ่งนี้เป็นไปไม่ได้หากเฟรมเวิร์กของคุณเป็นเพียงตำราเรียนหนาและแอปพลิเคชันใหม่ของคุณเป็นกระดาษเปล่า มันต้องใช้ความพยายามอย่างมหาศาลในการหาวิธีและจุดเริ่มต้น

    +

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

    +

    อย่างไรก็ตาม พลังของการตั้งค่ามาตรฐานไม่ได้ปราศจากอันตราย เมื่อ Rails ทำให้มันง่ายเกินไปในการทำหลายสิ่งหลายอย่าง เรามักจะคิดว่าแง่มุมทุกอย่างของแอปพลิเคชันสามารถสร้างจากแม่แบบที่ตัดไว้ล่วงหน้า แต่แอปพลิเคชันที่คุ้มค่าที่จะสร้างมักจะมีบางส่วนที่เป็นเอกลักษณ์ในบางวิธี อาจจะเพียง 5% หรือ 1% แต่ก็มีอยู่

    +

    สิ่งที่ยากคือการรู้ว่าเมื่อไหร่ควรเบี่ยงเบนจากการตั้งค่ามาตรฐาน การเบี่ยงเบนที่มีความสำคัญพอสมควรที่จะต้องมีการออกนอกเส้นทางหรือไม่? ฉันเชื่อว่าความคิดที่จะเป็นหิมะเกล็ดสวยงามและเป็นเอกลักษณ์ส่วนใหญ่เป็นความคิดที่ไม่ดี และต้นทุนของการออกนอก Rails นั้นต่ำกว่าที่ควรจะเป็น แต่ก็ยังมีบางกรณีที่คุณต้องพิจารณาทุกกรณีอย่างรอบคอบ

    From ee8c318d81122800a8032ee67b53b1d94a28006c Mon Sep 17 00:00:00 2001 From: zkan Date: Tue, 24 Sep 2024 16:22:09 -0400 Subject: [PATCH 4/7] Finish omakase section --- doctrine/th.html | 26 ++++++++++++-------------- 1 file changed, 12 insertions(+), 14 deletions(-) diff --git a/doctrine/th.html b/doctrine/th.html index 32cca7d6..58931030 100644 --- a/doctrine/th.html +++ b/doctrine/th.html @@ -1,8 +1,6 @@ --- title: The Rails Doctrine permalink: /doctrine/th -redirect_from: - - /doctrine/th/ ---
    @@ -56,7 +54,7 @@

    หลักการของ Rails

    1. เพิ่มประสิทธิภาพเพื่อความสุขของโปรแกรมเมอร์
    2. การตั้งค่ามาตรฐานเหนือการกำหนดค่า
      3. -
    3. เมนูเป็นแบบโอมะกะเสะ
      4. +
    4. เมนูแบบโอมากาเสะ
    5. ไม่มีแนวคิดเดียวที่ครอบคลุมทั้งหมด
    6. ยกย่องโค้ดที่สวยงาม
    7. จัดเตรียมเครื่องมือที่คม
      8. @@ -132,19 +130,19 @@

      การตั้งค่ามาตรฐานเหนือการ
      -

      เมนูเป็นแบบโอมะกะเสะ

      -

      How do you know what to order in a restaurant when you don’t know what’s good? Well, if you let the chef choose, you can probably assume a good meal, even before you know what “good” is. That is omakase. A way to eat well that requires you neither be an expert in the cuisine nor blessed with blind luck at picking in the dark. -

      For programming, the benefits of this practice, letting others assemble your stack, is similar to those we derive from Convention over Configuration, but at a higher level. Where CoC is occupied with how we best use individual frameworks, omakase is concerned with which frameworks, and how they fit together. -

      This is at odds with the revered programming tradition of presenting available tools as individual choices, and to bestow the individual programmer privilege (and burden!) of deciding. -

      You’ve surely heard, and probably nodded to, “use the best tool for the job”. It sounds so elementary as to be beyond debate, but being able to pick the “best tool” depends on a foundation that allows “best” to be determined with confidence. This is much harder than it seems. -

      It is a problem similar to that of the diner in a restaurant. And like picking each course in an eight-set meal, picking each individual library or framework is not a job done in isolation. The objective in both cases is to consider the whole evening or system. -

      So with Rails we decided to diminish one good, a programmer’s individual privilege to choose each tool in their box, for a greater one: A better tool box for all. The dividends are legion: +

      เมนูแบบโอมากาเสะ

      +

      คุณจะรู้ได้อย่างไรว่าควรสั่งอะไรในร้านอาหารเมื่อคุณไม่รู้ว่าอะไรดี? ถ้าคุณปล่อยให้เชฟเลือกให้ คุณก็สามารถคาดหวังได้ว่าจะได้รับมื้ออาหารที่ดีได้ แม้ว่าคุณจะยังไม่รู้ว่า "ดี" คืออะไร นั่นคือการ "โอมากาเสะ" ซึ่งเป็นวิธีการรับประทานอาหารที่ดี โดยที่คุณไม่จำเป็นต้องเป็นผู้เชี่ยวชาญในด้านอาหารหรือพึ่งพาดวงในการเลือกอาหาร

      +

      สำหรับการเขียนโปรแกรม ประโยชน์ของการปฏิบัตินี้ (การให้ผู้อื่นเลือก stack ให้คุณ) คล้ายกับที่เราได้รับจากหลักการ Convention over Configuration แต่ในระดับที่สูงขึ้น โดยที่ CoC เน้นที่วิธีการที่เราจะใช้เฟรมเวิร์กแต่ละตัวได้ดีที่สุด ในขณะที่โอมากาเสะมุ่งเน้นไปที่การเลือกเฟรมเวิร์ก และวิธีที่เฟรมเวิร์กเหล่านั้นจะทำงานร่วมกันได้

      +

      สิ่งนี้ขัดแย้งกับประเพณีที่เคารพนับถือในการเขียนโปรแกรม ซึ่งมักนำเสนอเครื่องมือต่าง ๆ ให้เป็นตัวเลือกแบบแยกส่วน และมอบสิทธิพิเศษ (และภาระ!) ให้กับโปรแกรมเมอร์แต่ละคนในการตัดสินใจเลือกเครื่องมือเอง

      +

      คุณคงเคยได้ยิน และอาจจะเห็นด้วยกับคำว่า "ใช้เครื่องมือที่ดีที่สุดสำหรับงาน" ฟังดูเหมือนเป็นหลักการพื้นฐานที่ไม่น่าจะมีข้อโต้แย้งอะไร แต่การเลือก "เครื่องมือที่ดีที่สุด" นั้นขึ้นอยู่กับพื้นฐานที่ช่วยให้เราตัดสินใจได้อย่างมั่นใจว่าอะไรคือ "ดีที่สุด" ซึ่งจริง ๆ แล้วมันยากกว่าที่คิดไว้

      +

      มันเป็นปัญหาที่คล้ายกับการเลือกอาหารในร้านอาหาร และเช่นเดียวกับการเลือกแต่ละคอร์สในมื้ออาหารแบบแปดคอร์ส การเลือกไลบรารี่หรือเฟรมเวิร์กแต่ละตัวไม่ใช่งานที่ทำแยกออกจากกัน เป้าหมายในทั้งสองกรณีคือการพิจารณาทั้งคืนหรือทั้งระบบโดยรวม

      +

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

        -
      1. There’s safety in numbers: When most people are using Rails in the same default ways, we have a shared experience. This common ground makes it much easier to teach and help people. It lays a foundation for debate on approach. We all watched the same show last night at 7, so we can talk about it the next day. It fosters a stronger sense of community.
        2. -
      2. People are perfecting the same, basic tool box: As a full-stack framework, Rails has a lot of moving parts, and how those work together is as important as what they do in isolation. Much of the pain in software comes not from the individual components, but from their interaction. When we all work on alleviating shared pain from components that are configured and fail in the same ways, then we all experience less pain.
        3. -
      3. Substitutions are still possible, but not required: While Rails is an omakase stack, it still allows you to replace certain frameworks or libraries with alternatives. It just doesn’t require you to. Which means you can delay those decisions until you’ve developed a clear, personal palate that may prefer the occasional difference.
        4. +
      4. ยิ่งมีคนใช้มากก็ยิ่งปลอดภัย: เมื่อคนส่วนใหญ่ใช้ Rails ในวิธีการเริ่มต้นแบบเดียวกัน เราจะมีประสบการณ์ร่วมกัน พื้นฐานนี้ทำให้การสอนและช่วยเหลือผู้อื่นง่ายขึ้นมาก มันสร้างพื้นฐานสำหรับการถกเถียงเรื่องแนวทางการทำงาน เปรียบเสมือนเราทุกคนดูรายการเดียวกันเมื่อคืนเวลา 7 โมง ดังนั้นเราจึงสามารถพูดคุยเกี่ยวกับมันในวันถัดไปได้ สิ่งนี้ช่วยสร้างความรู้สึกของชุมชนที่แข็งแกร่งขึ้น
        5. +
      5. ผู้คนกำลังปรับปรุงกล่องเครื่องมือจากพื้นฐานเดียวกัน: ในฐานะเฟรมเวิร์กแบบเต็มสแต็ก Rails มีหลายส่วนที่ทำงานร่วมกัน และวิธีที่ส่วนต่างๆ ทำงานร่วมกันนั้นสำคัญพอๆ กับการทำงานแยกกัน ความเจ็บปวดในซอฟต์แวร์ส่วนใหญ่มักไม่ได้มาจากส่วนประกอบแต่ละชิ้น แต่มาจากการทำงานร่วมกันของพวกมัน เมื่อเราทุกคนทำงานเพื่อบรรเทาปัญหาร่วมกันจากส่วนประกอบที่ถูกกำหนดค่าและเกิดความล้มเหลวในลักษณะเดียวกัน เราทุกคนก็จะเจอกับปัญหาน้อยลง
        6. +
      6. การเปลี่ยนแปลงยังสามารถทำได้ แต่ไม่จำเป็น: แม้ว่า Rails จะเป็นสแต็กแบบโอมากาเสะ แต่ก็ยังอนุญาตให้คุณแทนที่เฟรมเวิร์กหรือไลบรารีบางตัวด้วยทางเลือกอื่นได้ เพียงแต่มันไม่ได้บังคับให้คุณทำ ซึ่งหมายความว่าคุณสามารถเลื่อนการตัดสินใจเหล่านั้นออกไปจนกว่าคุณจะพัฒนารสนิยมที่ชัดเจนและเป็นส่วนตัว ซึ่งอาจจะชอบความแตกต่างในบางครั้ง
      -

      Because even the most learned and skilled programmers who come to and stay in Rails aren’t likely opposed to all matters of the menu. (If they were, they probably wouldn’t have stuck with Rails.) So they pick their substitutions with diligence, and then go on to enjoy the rest of the curated, shared stack alongside everyone else.

      +

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

      From a8e149e66d5a92ddbaaf17e3ede9f2ed21c17606 Mon Sep 17 00:00:00 2001 From: zkan Date: Thu, 21 Nov 2024 08:49:19 +0700 Subject: [PATCH 5/7] Translate push up a big tent --- doctrine/th.html | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/doctrine/th.html b/doctrine/th.html index 58931030..882c62fb 100644 --- a/doctrine/th.html +++ b/doctrine/th.html @@ -283,14 +283,14 @@

      ความก้าวหน้าสำคัญกว่าความ

      ยอมรับความหลากหลาย

      -

      With so many controversial ideas to its credit, Rails could quickly become an insular group of ideological hermits, if we required everyone to exhibit complete deference to all tenets, all the time. So we don’t!

      -

      We need disagreement. We need dialects. We need diversity of thought and people. It’s in this melting pot of ideas we’ll get the best commons for all to share. Lots of people chipping in their two cents, in code or considered argument.

      -

      So while this doctrine has described an idealized form, the everyday reality is much more nuanced (and interesting). Rails is capable of supporting such a large community under one tent exactly because there are so few if any litmus tests.

      -

      The continued success of RSpec, a DSL for testing I’ve often expressed grave discontent with, is perfect proof. I can rant until I’m blue in the face of why I don’t think it’s the way to go, and it can still blossom and prosper. That point is the far more important one!

      -

      The same is true for the advent of Rails as an API. While my personal focus and dedication is to the integrated system that includes the view, there’s undoubtedly room for Rails to do well with people who do want to distribute their clients and servers upfront. We should embrace this inasmuch as it can coexist as a secondary mission, and I believe it surely can.

      -

      Having a big tent doesn’t mean trying to be all things to all people, though. It just means you welcome all people to your party, and allow them to bring their own drinks. We need to lose none of our soul or values by offering others to join us, and we may well learn how to mix a new delicious drink or two.

      -

      This doesn’t come for free. It requires work to be welcoming. Especially if your goal isn’t just to attract more people who are just like the ones who are already part of the community. Lowering the barriers to entry is work we should always take seriously.

      -

      You never know when the next person who starts just fixing a misspelling in the documentation ends up implementing the next great feature. But you stand a chance to find out if you smile and say thank you for whatever small contribution that gets the motivation flowing.

      +

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

      +

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

      +

      ดังนั้น แม้ว่าหลักการนี้จะอธิบายรูปแบบที่เป็นอุดมคติ แต่ความเป็นจริงในทุกวันกลับซับซ้อนกว่านั้นมาก (และน่าสนใจ) Rails สามารถรองรับชุมชนขนาดใหญ่ภายใต้ร่มเดียวกันได้เพราะมีการทดสอบความเชื่อที่น้อยมากหรือเกือบไม่มีเลย

      +

      ความสำเร็จอย่างต่อเนื่องของ RSpec ซึ่งเป็น DSL สำหรับการทดสอบที่ผมมักจะแสดงความไม่พอใจอย่างรุนแรง ก็เป็นหลักฐานที่สมบูรณ์แบบ ผมสามารถวิจารณ์จนหน้าซีดว่าทำไมผมถึงไม่คิดว่ามันเป็นทางที่ดี และมันก็ยังคงเติบโตและเจริญรุ่งเรืองได้ จุดนี้ต่างหากที่สำคัญกว่ามาก!

      +

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

      +

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

      +

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

      +

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

    From f328440ccfd955eeae2dfc9beb784fe013bb7eab Mon Sep 17 00:00:00 2001 From: zkan Date: Thu, 21 Nov 2024 09:35:51 +0700 Subject: [PATCH 6/7] Translate optimize happiness --- doctrine/th.html | 40 ++++++++++++++++++++-------------------- 1 file changed, 20 insertions(+), 20 deletions(-) diff --git a/doctrine/th.html b/doctrine/th.html index 882c62fb..b4bb9d0a 100644 --- a/doctrine/th.html +++ b/doctrine/th.html @@ -72,16 +72,16 @@

    หลักการของ Rails

    เพิ่มประสิทธิภาพเพื่อความสุขของโปรแกรมเมอร์

    -

    There would be no Rails without Ruby, so it’s only fitting that the first doctrinal pillar is lifted straight from the core motivation for creating Ruby.

    -

    Ruby’s original heresy was indeed to place the happiness of the programmer on a pedestal. Above many other competing and valid concerns that had driven programming languages and ecosystems before it.

    -

    Where Python might boast that there’s “one and preferably only one way to do something”, Ruby relished expressiveness and subtlety. Where Java championed forcefully protecting programmers from themselves, Ruby included a set of sharp knives in the welcome kit. Where Smalltalk drilled a purity of message passing, Ruby accumulated keywords and constructs with an almost gluttonous appetite.

    -

    Ruby was different because it valued different things. And most of those things were in service of this yearning for programmer happiness. A pursuit that brought it at odds with not only most other programming environments, but also the mainstream perception of what a programmer was and how they were supposed to act.

    -

    Ruby took to not only recognize but accommodate and elevate programmer feelings. Whether they be of inadequacy, whimsy, or joy. Matz jumped implementational hurdles of astounding complexity to make the machine appear to smile at and flatter its human co-conspirator. Ruby is full of optical illusions where that which seems simple, clear, and beautiful to our mind’s eye actually is an acrobatic mess of wires under the hood. These choices were not free (ask the JRuby crew about trying to reverse-engineer this magical music box!), which is precisely why they’re so commendable.

    -

    It was this dedication to an alternate vision for programming and programmers that sealed my love affair with Ruby. It wasn’t just ease of use, it wasn’t just aesthetics of blocks, it was no one single technical achievement. It was a vision. A counter culture. A place for the misfits of the existing professional programming mold to belong and associate with the like of mind.

    -

    I’ve described this discovery of Ruby in the past as finding a magical glove that just fit my brain perfectly. Better than I had ever imagined any glove could ever fit. But it was even more than that. It was the event that marked my own personal transition from ‘doing programming because I needed programs’ to ‘doing programming because I fell in love with it as a mode of intellectual exercise and expression’. It was finding a fountain of flow and being able to turn it on at will. For anyone familiar with Csikszentmihalyi’s work, the impact of this is hard to overstate.

    -

    I’m not exaggerating when I say that Ruby transformed me and set the course for my life’s work. So deep was the revelation. It imbued me with a calling to do missionary work in service of Matz’s creation. To help spread this profound creation and its benefits.

    -

    Now I can imagine most of you shaking your heads with incredulity. I don’t blame you. If someone had described the experience above to me when I was still living under the “programming is just a tool” paradigm, I too would have shook my head. And then I would probably have laughed at the over-the-top use of religious language. But for this to be a truthful account, it also has to be honest, even if that’s off-putting to some or even most.

    -

    Anyway, what did this mean for Rails and how does this principle continue to guide its evolution? To answer that, I think it’s instructive to look at another principle that was often used to describe Ruby in the early days: The Principle of Least Surprise. Ruby should behave how you’d expect it to. This is easily described with a contrast to Python:

    +

    จะไม่มี 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 @@ -92,16 +92,16 @@

    เพิ่มประสิทธิภาพเพื่อความ >>> exit Use exit() or Ctrl-D (i.e. EOF) to exit {% endhighlight %} -

    Ruby accepts both exit and quit to accommodate the programmer’s obvious desire to quit its interactive console. Python, on the other hand, pedantically instructs the programmer how to properly do what’s requested, even though it obviously knows what is meant (since it’s displaying the error message). That’s a pretty clear-cut, albeit small, example of PoLS.

    -

    The reason PoLS fell out of favor with the Ruby community was that this principle is inherently subjective. Least surprising to whom? Well, to Matz. And people who are surprised in the same way as him. As the Ruby community grew, and the ratio of people who were surprised by different things than Matz grew with it, this became a source of fruitless bike-shedding on the mailing lists. So the principle faded to the background, lest to invite more debates going nowhere over whether person X was surprised by behavior Y or not.

    -

    So again, what does this have to do with Rails? Well, Rails has been designed with a similar principle to Principle of Least Surprise (To Matz). The Principle of The Bigger Smile (of DHH), which is just what it says on the tin: APIs designed with great attention paid to whatever would make me smile more and broader. When I write it out like this, that sounds almost comically narcissistic, and even I find hard to argue against that first impression.

    -

    But creating something like Ruby or Rails is at least at its outset a deeply narcissistic endeavor. Both projects sprung from the mind of a singular creator. But perhaps I’m projecting my own motivations onto Matz here, so let me narrow the scope of my proclamation to that which I know: I created Rails for me. To make me smile, first and foremost. Its utility was to many degrees subservient to its ability to make me enjoy my life more. To enrich my daily toil of wrangling requirements and requests for web information systems.

    -

    Like Matz, I at times went to silly lengths to serve my principle. One example is the Inflector, a class that understands just enough of the patterns and irregularities of the English language to map a Person class to a People table, Analysis to Analyses, and simply Comment to Comments. This behavior is now accepted as an unquestioned element of Rails, but the fires of controversy raged with great intensity in the early days when we were still coalescing the doctrine and its importance.

    -

    Another example that required less implementation effort, but triggered almost as much consternation: Array#second through #fifth (and #forty_two for good trolling measure). These alias accessors were deeply offensive to a very vocal constituency who decried the bloat (and near end of civilization, for good measure) of something that could as well be written as Array#[1], Array#[2] (and Array[41]).

    -

    But both decisions still, to this day, make me smile. I relish getting to write people.third in a test case or the console. No, that’s not logical. It’s not efficient. It may even be pathological. But it continues to make me smile, thus fulfilling the principle and enriching my life, helping to justify my continued involvement with Rails after 12 years of service.

    -

    Unlike, say, optimizing for performance, it’s tough to measure optimizing for happiness. This makes it an almost inherently unscientific endeavor, which to some renders it less important, if not outright frustrating. Programmers are taught to argue and conquer the measurable. That which has clear conclusions and where A can categorically be shown to be better than B.

    -

    But while the pursuit of happiness is hard to measure at the micro level, it’s a lot clearer to observe at the macro level. The Ruby on Rails community is full of people who are here precisely because of this pursuit. They boast of better, more fulfilled working lives. It’s in this aggregate of emotions that the victory is clear.

    -

    So thus we conclude: Optimizing for happiness is perhaps the most formative key to Ruby on Rails. It shall remain such going forward.

    +

    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 และมันจะยังคงเป็นเช่นนี้ต่อไป

    From 7925ff2b99afb9abb3e3dedb8924637f6111bfbd Mon Sep 17 00:00:00 2001 From: zkan Date: Fri, 22 Nov 2024 20:11:33 +0700 Subject: [PATCH 7/7] Finish no one paradigm --- doctrine/th.html | 26 +++++++++++++------------- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/doctrine/th.html b/doctrine/th.html index b4bb9d0a..9348fbe2 100644 --- a/doctrine/th.html +++ b/doctrine/th.html @@ -153,19 +153,19 @@

    เมนูแบบโอมากาเสะ

    ไม่มีแนวคิดเดียวที่ครอบคลุมทั้งหมด

    -

    There’s a strong emotional appeal to picking a single central idea and following it to the logical conclusion as your architectural underpinning. There’s a purity in such discipline, so it’s clear why programmers are naturally attracted to this bright light.

    -

    Rails isn’t like that. It isn’t a single, perfect cut of cloth. It’s a quilt. A composite of many different ideas and even paradigms. Many that would usually be seen in conflict, if contrasted alone and one by one. But that’s not what we’re trying to do. It isn’t a single championship of superior ideas where a sole winner must be declared.

    -

    Take the templates we build the view in our Rails MVC pie with. By default, all the helpers that allow us to extract code from these templates are just a big pot of functions! It’s a single namespace even. Oh the shock and the horror, it’s like PHP soup!

    -

    But I contend that PHP had it right when it came to presenting individual functions that rarely needed to interact, as is the case with much abstraction in view templates. And for this purpose, the single namespace, the big pot of methods, is not only a reasonable choice, but a great one.

    -

    This doesn’t mean we don’t occasionally want to reach for something more object-oriented when building views. The concept of Presenters, where we wrap many methods that are interdependent with each other and the data below it, can occasionally be the perfect antidote to a soup of methods turned sour by dependencies. But it’s generally proved to be the rare rather than common fit.

    -

    In comparison, we generally treat the model in our MVC layer cake as the prime bastion of object-oriented goodness. Finding just the right names for objects, increasing the coherence, and lowering the coupling is the fun of domain modeling. It’s a very different layer from the view, so we take a different approach.

    -

    But even here we don’t subscribe to single-paradigm dogma. Rails concerns, the specialization of Ruby’s mixins, are often used to give the individual models a very wide surface area. This fits well with the Active Record pattern by giving the concerned methods direct access to the data and storage they interact with.

    -

    Even the very foundation of the Active Record framework offends some purists. We’re mixing the logic needed for interfacing with the database directly with the business domain and logic. Such conflation of boundaries! Yes, because it proved to be the practical way to skin a web-app cat that virtually always talks to a database of some sort to persist the state of the domain model.

    -

    To be so ideologically flexible is what enables Rails to tackle such a wide array of problems. Most individual paradigms do very well within a certain slice of the problem space, but become awkward or rigid when applied beyond its natural sphere of comfort. By applying many overlapping paradigms, we cover the flanks and guard the rear. The final framework is far stronger and more capable than any individual paradigm would have allowed it to be.

    -

    Now, the cost of this polyamorous relationship with the many paradigms of programming is conceptual overhead. It’s not enough to just know object-oriented programming to have a good time with Rails. It’s preferable to be well served with procedural and functional experiences as well.

    -

    This applies to the many sub-languages of Rails as well. We don’t try to shield you that much from having to learn, say, JavaScript for the view or SQL for the occasional complicated query. At least not to reach the peaks of possibilities.

    -

    The way to alleviate some of that learning burden is to simply just make it easy to get started, make something of real value, before you understand every single aspect of the framework. We have a rush to Hello World for this reason. Your table already prepared and an appetizer served.

    -

    The thinking is that by giving something of real value early, we’ll encourage the practitioners of Rails to level-up quickly. Accept their journey of learning as a joy, not an obstacle.

    +

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

    +

    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 พัฒนาตัวเองอย่างรวดเร็ว ยอมรับการเดินทางของการเรียนรู้ให้เป็นความสุข ไม่ใช่อุปสรรค