2004년 말, 나는 미국의 큰 자동차 회사 중 하나를 내 절친한 친구인 에이슬락 헬소이(Aslak Helloesoy)와 함께 자동차 기업 컨설팅을 할 때 였다. 그 컨설팅은 어려운 정치적 상황이 복잡하고, 속이었을 뿐만 아니라 기술적인 어려움을 안은 채이 많았기도 했고 데드라인을 가혹하게 요구 받는 상황에서 이루어졌기 때문에 무척 도전적인 것이었다. 이러한 데드라인은 일반적인 것과는 달랐다.우리가 흔히 접하는 것과는 달랐다. 이 데드라인을 넘긴다면 고객이 하루에 백만 달러의 지체보상금을 내야 하는 상황이 발생한다. 나는 압력에 시달렸다.
우리가이처럼 불확실한 결정을 해야 했을 때, 우리 팀은 에이슬락의 펫프로젝트인 데미지컨트롤이라는 지속적인 통합 시스템에 근거해서 판단하기로을 내려 보기로 하였했다. 그것은바로 우리의 고용주인모기업(?) ThoughtWorks에서 만든 루비 기반의 훌륭한 크루즈 컨트롤(역자주: CruiseControl – 자바기반의 오픈 소스 통합 프레임웍을 빗대어 말함) 서버였다.
문제는 데미지컨트롤이 완성된 제품이라고 할 수 없는 것이라는 데 있었다. 그리고 많은 루비관련 사항들처럼 윈도우즈 시스템에서는 잘 동작하지 않았다. 사실 몇몇 이유들은를 지금 다 기억할 수는 없지만 구형 윈도우즈 2000 서버에 배포를 해야만 했었고 스타팀(StarTeam)서버에 소스 저장소를 써야 했다. (이런!)
에이슬락은 우리가 몇 주 동안 데미지컨트롤과 C기반으로 된 루비 Win32 프로세스 라이브러리의 내부 어플리케이션애플리케이션 코드들을 광범위하게 페어프로그래밍하는 과정 전면에 걸쳐서 도움이 필요했다. 그러나 그때 나는 이미 8년이라는여 동안 엔터프라이즈 자바 프로그래밍을 해오던 차였고, 경력을 가지고 훌륭한 툴인 IntelliJ IDE에 깊이 빠져들어 있었다. 그때 당시에 내가 얼마나 루비를 싫어했는지 여기서 표현하기도 어렵다.
그래서 무엇이 바뀌었나? 글쎄, 시작하는 단계에서는 결국 스트레스가 가득한 일 속에서 살아 남았고 ThoughtWorks의 런던이 아닌 해외에서 비교적 쉬운 일을 맡게 되었다. 그리고 한달 만에 주목할 만한 블로그스피어블로고스피어에서가 레일스라는 신생 웹 프레임웍에대해 열광하는하며 들썩이는 것을 바라보면서 루비가는 나를 다시 사로잡았다. 나는 루비에게 새로운 기회를 주기로 마음 먹었다. 결국 나쁘지 않은 선택이었다? 나는 ThoughtWorks의 내부 용도로 혁신적인 소셜 네트워킹 시스템을 빠르게 구축했다.
2005년 2월 몇 주간의 첫 번째 레일스에 대한 첫 경험이 내 인생의 변화를 가져왔다. 웹 어플리케이션을 구축하면서 내가 다년간 배워왔던 성공사례들이은 내 인생에서 한번도 보지 못한 가장 우아하고 간결한 코드로 작성된 한 프레임웍 안으로 녹아 들어 갔다. 자바에 대한 흥미는 완전히(비록 IntelliJ를 거의 한해 더 사용하긴 했지만) 사라져 버렸다. 나는 ThoughtWorks 내부 외부 모두에게 전파시키기 위해서 루비와 레일스에 대한 블로깅에 열중했다을 열심히 하였다. 그 이후에 일어나는 일들은 역사가 되었다.
이 책을 쓰기 시작한 2007년 이래로 내가 개척한 레일스 비즈니스로 ThoughtWorks는 전세계 수입의 거의 절반을 벌어들였다. 그리고 큰 제품 부서를 설립해서 대량으로 루비 기반의 상용 소프트웨어를 계속 만들어 내었다냈다. 이런 소프트웨어들에게는 에이슬락의 지속적인 빌드 시스템인 크루즈컨트롤(CruiseControl.rb)이 있었다. 크루즈 컨트롤은 레일스 코어 팀에서 공식적인 지속적인 통합 서버가 되는 영광을 갖게 되었다.
나와 같은 경험 많은 엔터프라이즈 부류들이 루비와 레일스에 빠져드는 이유는 무엇일까? 주어진 요구사항을 수행하기 위해서 자바와 마이크로소프트의 기술을 사용해서 만들어진 복잡한 솔루션은 완전히 받아들일 수 없었다수용하기가 매우 어려웠다. 지나친 복잡함으로복잡도로 인해서 개개인이 프로젝트에 대한 이해도가 떨어졌고 팀 내에는 과도한 커뮤니케이션의 증가가 발생했다 팀에서는 커뮤니케이션이 과도하게 늘어났다. 디자인 패턴 숭배자들이 성능의 강박관념에 더해서사로잡혀 강조하는 것들은 (그들의 플랫폼에서) 순수한 어플리케이션애플리케이션 개발의 즐거움을 약화시켜 버렸다.
레일스 커뮤니티에서는 어떤 경우에도 동료들간의 압력이 없다. DHH (David Heinemeier Hansson) 는 자기를 행복하게 하는 언어를 선택하였다. 레일스는 아름답다고 느끼는 코드에서 태어났다. 이런 종류의 일련의 어조가 레일스 커뮤니티를 지지하고 있다. 레일스의 많은 부분은 주관적이다. 사람들은 레일스를 사용하거나 혹은 사용하지 않는다. 그러나 레일스를 사용하는 사람들은 그것을 사용하지 않는 사람들에 대해서 적개심을 갖고 있지 않다. 단지 부드럽게 독려할 뿐이다.
-- 팻 매덕스(Pat Maddox)
루비는 아름답다. 루비로 코딩 하는 것은 아름답다. 내가 아는 사람 중에 루비를 사용하게 된 모든 사람들은 이전보다 행복해졌다고 말하고 있다. 다른 어떠한 것보다도 이러한 이유 때문에 루비와 레일스는 특히 엔터프라이즈 컴퓨팅 분야를 흔들게 되었다. 레일스와 관계 맺기 이전에는 늘 실제로 필요한 것들과 관계가 없는 복잡한 요구사항에 기반을 둔 프로젝트에서 일하곤 했었다. 내 마음을 위축하는 일련의 프레임웍들의 선택과 통합에 지쳐갔고, 추한 코드들에 지쳐갔다.
반면에 루비는 아름답고 다이내믹한 고수준언어다. 루비 코드는 우리가 해결해야 하는 문제 영역과 가깝게 묘사할 수 있는 사람의 언어와 스타일이 유사하기 때문에 읽고 쓰기 쉽다. 코드가 제품에까지 이어지고 유지 보수하는 프로그래머들의 이해도가 높아질 수 있기 때문에 가독성의 향상은 단기적 그리고 장기적으로 많은 이익을 가져온다.
내 경험상으로 루비로 작성된 프로그램은 자바나 C# 으로 작성된 코드보다 대부분 적은 라인의 코드를 가지고 있다. 적은 코드 기반은 유지보수하기 쉽고 장기간의 유지보수는 성공적인 소프트웨어 프로젝트의 큰 이익으로 돌아올 것이다. 또한 문제가 생겼을 때 고급 디버깅 툴 없이도 좀더 빠르게 디버깅 할 수 있다.
애자일 운동과 유사한 방식으로 태어난 레일스는 소프트웨어 엔지니어들이나 컴퓨터 과학자 들이 아니라, 어플리케이션 개발자들에게 필요한 모든 것을 제공한다. 프로젝트의 궁극적 성공을 실제적으로 좌우하는 것은 인간 중심적인 개발이라는 면에서 레일즈는 불필요하게 복잡한 것 대하여 적극적인 공격을 함으로써 가장 빛을 발휘한다. 우리는 레일스로 프로그래밍할 때 즐겁고, 그것이 우리를 성공으로 이끈다.
레일스에 의해 제공되는 툴과 기술적인 기반은 우리가 비즈니스적인 가치를 제공하는데 집중할 수 있도록 모든 것을 포함하고 있다. 최소 놀람 원칙은 레일스의 명료하고 우아한 디자인에 나타난다. 가장 멋진 것은 레일스가 완전한 무료 오픈 소스 소프트웨어 이기 때문에 소스코드를 브라우징 하는 것으로 대부분 어려운 문제들까지도 해답을 얻을 수 있다는 것이다.
DHH는 얼리아답들타들이 즐기는 경쟁적 엣지가 줄어들 수 있기 때문에 레일스가 주류로 편입되는 데에는 특별히 관심이 없다고 종종 이야기해 왔다. 얼리아답타들은 주로 개별적이고 웹 디자이너와 프로그래머 소 그룹으로PHP 세계에서 나와 대군을 이루어 왔다.
원한다면 나를 이상주의자 라고 불러도 좋다. 하지만 나는 심지어 크고 보수적인 회사에서 일하는 엔터프라이즈 개발자들이라도 이 도구를 주고 그것을 활용하도록 격려한다면 좀더 효율적이고 혁신적으로 일할 수 있게 될 것 이라고 믿는다. 이것이 매년 많은 사람들이 레일스 세계로 뛰어드는 이유다.
아마도 엔터프라이즈 개발자들이 루비와 레일스를 적용함에 있어 궁극적으로 가장 말이 많고 열정적인 사람들일 것이다. 왜냐하면 현상을 유지한다면 가장 많이 잃을 사람들이 그들이기 때문이다. 엔터프라이즈 개발자들은 “스펙이 구현보다 중요하다”, “구현은 기계적이고 하찮은 일이다” 같은 가정하에서 지속적으로 대량해고와 잘못된 아웃소싱의 희생양이 되어왔다.
스펙은 실제로 구현보다 중요한가? 대부분의 프로젝트에서는 그렇지 않다. 단순한 프로젝트에서는 구현이 사소한 것일까? 물론 아니다! 특히 엔터프라이이즈 환경에서는 아래와 같이 소프트웨어 개발이 어려워지는 중요한 이유들이 있다.
•이해하기 어려운 레거시 시스템.
•투자 은행 같은 고도로 복잡한 비즈니스 영역.
•실제로 원하는 것이 무엇인지 모르는 이해관계자(주주)와 비즈니스 분석가.
•줄어드는 연간 예산 때문에 생산성을 저해하는 관리자.
•프로젝트를 활발하게 고의 지연 시키는 최종 사용자.
•정치! 머릿속에 달라 붙어있는 잘라내 버려야 하는 걱정.
>>>>>>여기까지 번역한 내용입니다. 아래부터는 아직 해석만 한 상태입니다.
포춘지 1000대 기업을 위한 컨설팅을 해온 이래로 나는 이러한 상황에서 거의 10년 동안을 숨쉬고 살았지만 결국 우연히 아주 강력한 개념과 마주치게 되었다. 이 개념은 안전하게 일하기 위한 정치를 초월한 강력하고, 새로운 기회의 문을 열게 해주는 실현 가능한 대안이다.
생산성에서 출발한 이러한 대안은 이례적인 경우다! 나는 아무도 결코 대신해서 희생해줄 수 없는 정치적인 자살 까지도 시도하는 일에 있어서 명백하게 효율적으로 되는 것에 대해서 말하고 있다. 나는 결과물을 걸출하게 만들어주도록 실행하는 노력, 심지어 프로젝트에서 가장 냉소적이고 냉혹한 이해관계자(주주)를 위한 즐거움의 눈물을 가져올 노력에 대해서 말하고 있다. 규칙적으로 어플리케이션을 변함 없는 열정적인 최종 사용자를 만들어낼 훌륭한 상태로 세련되게 하기 위한 시간을 가지라는 뜻이다.
By simply being exceptional, you can be that individual (or team) that keeps clients happy and paying their invoices on time, or that survives layoffs year after year, because the decision-makers say: “Oh, there’s no way we can afford to lose them.”
이례적으로 당신은 개인이나 팀이 되어 고객을 행복하게 유지시켜주고 제시간에 구매서를 지불하고 또는 내년의 감원에서 살아남고
의사결정권자는 이렇게 말했기 때문에 : “우리가
잠시 숨좀 돌리고, 나는 회의론적인 말들로 비난하려는 것이 아니다. 하지만 내가 말하려는 것들은 무의미한 속임수가 아니다. 내가 레일스로 옮겨간 이후 내 삶을 묘사해 보았다. 이 책은 레일스가 비밀(비밀이 아닐 수도) 무기가 되어 불신이 많은 소프트웨어 개발의 세계에서 성공하기 위한 도움을 줄 것이라고 생각한다.
My contributors and I draw on our collective experience and industry knowledge to show you how to deliver practical results using Ruby on Rails on your projects, giving you the ammunition needed to justify your choice of technology and even defeat objections that will undoubtedly come your way.
내 기여자들과 나는 우리의 축적된 경험과 산업 지식들을 이용해서 레일즈를 프로젝트에 사용해서 얻은 유용한 결과들을 어떻게 전달할 것인가를 보여주기 위해 기술적인 선택을 정당화하고 심지어는 틀림없이 당신의 방식에 반대하는 의사들을 물리칠 수 있도록 필요한 정보를 줄 것이다.
Since we know there are never any silver bullets, we’ll also warn you about situations where choosing Rails would be a mistake. Along the way, we’ll analyze each of the components of Rails in depth and discuss how-to extend them when the need arises.
어떠한 만능 해결책도 없다는 것을 알고 있기 때문에, 레일스의 선택도 또한 실수가 될 수 있다.Along the way, 레일스의 각 컴포넌트들을 깊숙히 분석할 것이고 어떻게 필요에 따라서 확장할 수 있는지 검토할 것이다.
Ruby is an extremely flexible language, which means there are myriad ways to customize the behavior of Rails yourself. As you will learn, the Ruby way is all about giving you the freedom to find the optimal solution to the problem at hand.
루비는 매우 유연한 언어이다. 유연하다는 것은 직접 레일스의 동작을 커스터마이징 하는데 무수히 많은 방법이 있다는 의미이다. 루비 방식을 배우게되면문제를 해결하는 최선의 방법을 찾기 위한 자유를 얻게 된다.
As a reference work, this book functions as a guide to the Rails API and the wealth of Ruby idioms, design approaches, libraries, and plugins useful to the Ruby on Rails enterprise developer.
레퍼런스와 마찬가지로 이 책은 레일스 API 그리고 루비스러운 표현들, 디자인적인 접근방법, 라이브러리, 레일스 엔터프라이즈 개발자에게 유용한 플러그인등의 풍부한 가이드로서의 역할을 한다.
Before going on, I should mention that part of what makes Rails exceptional is that it is opinionated software, written by opinionated programmers. Likewise, this is an opinionated book, written by opinionated writers.
시작하기 전에 무엇이 레일스를 이렇게 자부심 강한 프로그래머들에 의해서 작성된 자부심 강한 우수한 소프트웨어로 만드는가에 대한 부분을 언급 하려고 한다. 마찬가지로 이책 또한 자부심강한 저자에 의해 쓰여진 자부심 강한 책이다.
Here are some of the opinions about development that influence this book. You don’thave to agree with all of them—just be aware of their influence:
이 책에 영향을 받은 개발자들의 의견을 몇개 소개한다. 이런 의견에 동의해야만할 필요는 없으며
•Developer motivation and productivity trump all other factors for project success.
•The best way to keep motivated and productive is to focus on delivering business value.
•Performance means “executing as fast as possible, on a given set of resources.”
•Scalability means “executing as fast as needed, on as many resources as needed.”
•Performance is irrelevant if you can’t scale.
•If you can scale cheaply, milking every ounce of performance from your processorsshould never be your first priority.
•Linking scalability to choice of development tools is a pervasive mistake in the industryand most software does not have extreme scalability requirements.
•Performance isrelated to choice of language and tools because higher-level languages areeasier to write and understand. There is wide consensus that the performance problemsin most applications are caused by poorly written application code.
•Convention over configuration is a better way to write software. Huge XML configuration files must be eliminated!
•Code portability, the ability to take code and run it on a different hardware platform, isnot particularly important.It’s better to solve a problem well even if the solution only runs on one platform.Portability is irrelevant if your project fails.
•Database portability, the ability to run the same code on different relational database systems is rarely important and is almost never achieved.
•Presentation is very important, even for small projects. If your application looks bad,everyone will assume it is written badly.
•Allowing technology to dictate the approach to solving a business problem is usually abad idea; however, that advice shouldn’t be used as an excuse to stick with inferior technology.
•The benefits of generalized application components are dubious. Individual projects usually have very particular business needs and wildly different infrastructure requirements,making parameterized reuse very difficult to achieve in practice.Phew, that’s a lot of opinions. But don’t worry, The Rails Wayis primarily a referencework, and this list is the only one of its kind in the book. Speaking of which….
This book is not a tutorial or basic introduction to Ruby or Rails. It is meant as a day-to-dayreference for the full-time Rails developer. At times we delve deep into the Rails codebase toillustrate why Rails behaves the way that it does, and present snippets of actual Rails code.
The more confident reader might be able to get started in Rails using just this book, extensive online resources, and his wits, but there are other publications that are more introductory in nature and might be a wee bit more appropriate for beginners.
I am a fulltime Rails application developer and so is every contributor to this book. Wedo not spend our days writing books or training other people, although that is certainly something that we enjoy doing on the side.
I started writing this book mostly for myself, because I hate having to use online documentation, especially API docs, which need to be consulted over and over again. Since theAPI documentation is liberally licensed (just like the rest of Rails), there are a few sections ofthe book that reproduce parts of the API documentation. In practically all cases, the API documentation has been expanded and/or corrected, supplemented with additional examples and commentary drawn from practical experience.
Hopefully you are like me—I really like books that I can keep next to my keyboard, scribble notes in, and fill with bookmarks and dog-ears. When I’m coding, I want to be able toquickly refer to both API documentation, in-depth explanations, and relevant examples.