Rails 5实战指南：深度参考与实践经验

需积分: 9 34 浏览量更新于2024-07-19 收藏 3.26MB PDF 举报

《The Rails 5 Way》是由Obie Fernandez编写的，这是一本专为经验丰富的Rails开发者设计的参考书籍，而非初级教程或Ruby/Rails的基础入门读物。作者的初衷是让全职Rails开发者通过一次性的阅读来熟悉框架，然后在日常开发中作为查阅资料。书中的内容深度适合那些有一定基础的读者，他们可以通过这本书、在线资源和实践经验进行学习和实践。本书的特色在于其结构紧凑，包含了Rails 5的配置与环境管理、Bundler的使用、启动脚本、默认初始化器等实用部分。例如，章节1讨论了Rails的配置，包括如何利用Bundler管理项目依赖，以及如何编写和理解启动脚本，这些都是开发者日常工作中不可或缺的知识。此外，书中还包含了对API文档的扩展和实际经验的注释，使得开发者能够更直观地理解和应用这些内容。《The Rails 5 Way》遵循Leanpub出版模式，作者在写作过程中不断获取读者反馈，不断迭代优化内容，以确保提供最符合需求的书籍。书中也提及了Obie Fernández的其他著作，如《How to Eat Nachos and Influence People》、《The Lean Enterprise》等，展示了作者在不同领域的广泛涉猎和深厚底蕴。对于初学者来说，虽然这本书可能不是首选的入门教材，但其详细且深入的内容可以帮助有经验的开发者提升对Rails 5的理解和技能，同时也能为那些希望通过实践和经验学习的开发者提供一个宝贵的学习资源。如果你喜欢能够在键盘旁随时查阅的书籍，或者希望在编程时能快速找到API文档、深入解释和相关示例，《The Rails 5 Way》将是一个值得收藏的参考书籍。

Foreword iii

along named Rist, Rast, or Rost, he’ll be an expert in that too. It’s an odd

speciality, but he’s clearly got it locked down.) But I do want to suggest a

controversial possibility: maybe the standards of expertise in our industry are

so low that all you have to do, to radically outpace every Rails programmer

you know, is actually read this book, start to finish.

I know it’s over 700 pages, but every single book in George RR Martin’s A

Song of Ice and Fire is longer than that, and I know at least half the people

who buy this book will have read that entire series. If you can sit through

an endless list of pheasant pies and random food involving persimmons, as if

anyone even knows what a persimmon is, you can sit down and invest some

time in actually getting good at the thing that you do for a living. Stranger

things have happened.

Rails is often seen as a newbie-friendly shorthand for building web apps.

Unwise people say that it makes building web apps so simple that anybody

can do it. I’m going to recommend that you regard that point of view as utter

bullshit. Here’s an alternative paradigm: Rails is a user interface for web

development which streamlines complex tasks. It doesn’t take the complexity

away. It streamlines your interaction with that complexity. There are two

things you should really watch out for here.

The first is that in programming, all abstractions are ultimately leaky ab-

stractions. For example, it’s irresponsible to write any kind of code which

handles money and currency if you don’t understand the basics of floating-

point math, including the reasons why computers can’t actually do floating-

point math. It’s literally impossible to represent many decimal fractions as

binary fractions, and computers represent everything in binary because they

ultimately run everything through logic gates. This means that it’s impossible

to accurately represent certain numerical values as floating-point numbers,

and people can take that mathematical impossiblity quite personally when

it affects the accuracy of their bank account balances. In other words,

the realities of calculation in silicon are very important when you’re doing

financial transactions. That’s just an example, but in every case, if you’ve got

a system which makes complex stuff simple, it’s still a really good idea to know

what those underlying complexities ultimately are.

The second thing you should understand, to avoid the majority of pitfalls in

Rails, is that building a good user interface is a lot of work. Every project out

there will encounter the tricky situation where you get the first 90% of the

problem out of the way, and then you discover that the remaining 10% of the

problem – all the random little edge cases and details – will take as much code

as the first 90% did. User interface code is all about that remaining 10%. And

Rails really is a user interface for web development. So entire libraries within

Rails, such as Active Relation, are dedicated to that little 10%.

Foreword (to The Rails 4 Way)

A long time ago, I was an intern at a technology company. We had “deploy

week,” meaning that after deploying, we took an entire week to fight fires.

Moving our code to the production environment would inevitably cause

unexpected changes. One day, I read a blog post titled “Unit Testing with

Ruby on Rails,” and my life was forever changed. I excitedly went and told

my team that we could write code to check whether our code worked before

deploying, but they weren’t particularly interested. A few months later, when

a friend asked me if I wanted to be the CTO of his startup, I said, “Only if I

can do it in Ruby on Rails.”

My story was fairly typical for that period. I didn’t know anything about Ruby,

but I had to write my application in Rails. I figured out enough Ruby to fake

it and cobbled together an application in record time. There was just one

problem: I didn’t really understand how it actually worked. This is the deal

everyone makes with Rails at the start. You can’t think about the details too

much because you’re flying to the sky like a rocket.

This book, however, isn’t about that. When I read

The Rails Way

for the first

time, I felt like I truly understood Rails for the first time. All those details

I didn’t fully understand were now able to be grokked. Every time someone

said, “Rails is magic,” I would smile to myself. If Rails was magic, I had peered

behind the curtain. One day I decided that I should write some documentation

to help dispel those kinds of comments. One commit became two; two became

twenty. Eventually, I was a large contributor in my own right. Such a long way

for someone who had just a few short years earlier never heard of a unit test!

As Rails has changed, so has The Rails Way. In fact, one criticism you could

make of this book is that it’s not actually “the Rails way”; after all, it teaches

you HAML instead of ERb! I think that this criticism misses the mark. After all,

it’s not 2005 anymore. To see what I mean, go read the two forewords from

the previous editions. They appear right after this one… I’ll wait.

Done? David’s foreword was quite accurate for both Rails 2 and The Rails Way.

At that time, Rails was very much “not as a blank slate equally tolerant of every

kind of expression.” Rails was built for what I call the “Omakase Stack”: you

have no choice, you get exactly what Chef David wants to serve you.

Omakase is a Japanese term used at sushi restaurants to leave the selection to the chef. To learn more about

the Omakase stack, read http://words.steveklabnik.com/rails-has-two-default-stacks

Foreword (to The Rails 4 Way) vi

Yehuda’s foreword was also quite accurate–but for Rails 3 and The Rails 3

Way. “We brought this philosophy to every area of Rails 3: flexibility without

compromise.” With Rails 3, you get the Omakase stack by default, but you are

free to swap out components: if you don’t like sushi, you can substitute some

sashimi.

There was a lot of wailing and gnashing of teeth during the development of

Rails 3. Jeremy Ashkenas called it “by far the worst misfortune to ever happen

to Rails.” Rails 3 was an investment in the future of Rails, and investments can

take awhile to pay off. At the release of Rails 3, it seemed like we had waited

more than a year for no new features. Rails was a little better, but mostly the

same. The real benefit was where it couldn’t be seen: in the refactoring work.

Rails 1 was “red-green.” Rails 2 was “red-green.” Rails 3 was “refactor.” It

took a little while for gem authors to take advantage of this flexibility, but

eventually, they did.

And that brings us now to Rails 4 and The Rails 4 Way. This book still

explains quite a bit about how Rails works at a low level, but also gives you

an alternate vision from the Omakase Stack, based on the experience and

talent of Hashrocket. In many ways, The Rails 4 Way, Agile Web Development

with Rails, and Rails 4 in Action are all “the Rails way.” Contemporary Rails

developers get the best of both worlds: They can take advantage of the rapid

development of convention over configuration, but if they choose to follow

a different convention, they can. And we have many sets of conventions to

choose from. It’s no longer “David’s way or the highway,” though David’s way

is obviously the default, as it should be.

It has been an amazing few years for Rails, and it has been a pleasure to take

part in its development. I hope that this book will give you the same level of

insight and clarity into Rails as it did for me, years ago, while also sparking

your imagination for what Rails will undoubtedly become in the future.

—Steve Klabnik, Ruby Hero

Foreword (to The Rails 3 Way)

From the beginning, the Rails framework turned web development on its head

with the insight that the vast majority of time spent on projects amounted

to meaningless sit-ups. Instead of having the time to think through your

domain-specific code, you’d spend the first few weeks of a project deciding

meaningless details. By making decisions for you, Rails frees you to kick off

your project with a bang, getting a working prototype out the door quickly.

This makes it possible to build an application with some meat on its bones in

a few weekends, making Rails the web framework of choice for people with a

great idea and a full-time job.

Rails makes some simple decisions for you, like what to name your controller

actions and how to organize your directories. It also gets pretty aggressive,

and sets development-friendly defaults for the database and caching layer

you’ll use, making it easy to change to more production-friendly options once

you’re ready to deploy.

By getting so aggressive, Rails makes it easy to put at least a few real users

in front of your application within days, enabling you to start gathering the

requirements from your users immediately, rather than spending months ar-

chitecting a perfect solution, only to learn that your users use the application

differently than you expected.

The Rails team built the Rails project itself according to very similar goals.

Don’t try to overthink the needs of your users. Get something out there that

works, and improve it based on actual usage patterns. By all accounts, this

strategy has been a smashing success, and with the blessing of the Rails core

team, the Rails community leveraged the dynamism of Ruby to fill in the gaps

in plugins. Without taking a close look at Rails, you might think that Rails’

rapid prototyping powers are limited to the 15-minute blog demo, but that

you’d fall off a cliff when writing a real app. This has never been true. In

fact, in Rails 2.1, 2.2 and 2.3, the Rails team looked closely at common usage

patterns reflected in very popular plugins, adding features that would further

reduce the number of sit-ups needed to start real-life applications.

By the release of Rails 2.3, the Rails ecosystem had thousands of plugins, and

applications like Twitter started to push the boundaries of the Rails defaults.

Increasingly, you might build your next Rails application using a non-relational

database or deploy it inside a Java infrastructure using JRuby. It was time to

take the tight integration of the Rails stack to the next level.

剩余1210页未读，继续阅读

WindStand

粉丝: 35
资源: 367

Rails 5实战指南：深度参考与实践经验

The Rails 5 Way(4th) 无水印原版pdf

The Rails Way

The Rails 5 way 英文原版

Suricata的官方规则库emerging-all.rules有哪些ssrf的攻击检测规则呢

从哪里进入gitlab内置的数据库gitlab-rails dbconsole --database main

Recipe: gitlab::gitlab-rails

bitnami-redmine-4.2.3-0-windows-x64-installer.exe

CentOS下用Phusion Passenger方式部署rails应用 -- redmine示例

bitnami-redmine-3.4.6-0-linux-x64-installer.run下载

redmine4.2安装

最新资源