• Beyond The Rails Way

  • Hi,

  • 안녕하세요!

  • What is Rails for you?
  • 여러분에게 레일즈는 무엇인가요?
  • Is it just a technology? Is it about the community?
  • 그저 하나의 기술인가요? 아니면 하나의 커뮤니티인가요?
  • Do you remember the first time you scaffolded a Rails application? 
  • 맨 처음 스캐폴딩으로 레일즈 애플리케이션을 만든 순간을 기억하세요?
  • How did it feel?
  • 어떤 느낌이었나요?
  • Were you proud of achieving so much in so little time? Did you impress anyone by using Rails?
  • 순식간에 많은 걸 해낼 수 있다는 사실에 뿌듯함하셨나요? 다른 사람에게 자랑도 하셨나요?
  • Rails is no longer the youngest technology around. Did it change anything?
  • 레일즈가 더 이상 최신 기술이 아니라는 사실이
  • Did you ever think how Rails ideas helped to shape the world? Did you notice how many startups choose Rails as the technology? It’s amazing that sometimes those people don’t fully know their business idea yet, but they know it will be implemented in Rails!
  • 레일즈라는 아이디어가 세상을 어떻게 바꿨는지 생각해 보셨나요? 얼마나 많은 스타트업들이 레일즈를 선택했는지 알고 계시나요? 때로는 비즈니스 모델이 제대로 정해지지도 않았는데 레일즈를 선택하기도 합니다. 레일즈로 그 아이디어가 구현될거라는 걸 알기 때문이죠.
  • Rails changed the business world. For the better.
  • 레일즈는 비즈니스를 바꿔놨습니다. 더 낫게요.
  • It was no longer so expensive to come up with a prototype or with an MVP. More ideas could be validated.
  • 시제품이나 MVP(Minimum viable product; 최소 기능 제품)를 만드는게 이제 그렇게 비싸게 먹히지 않죠. 더 많은 아이디어를 검증할 수 있다는 뜻입니다.
  • Some of the ideas were totally wrong. They didn’t have the market fit. Still, their authors lost less money than they would by choosing other (at that time) technology.
  • 어떤 아이디어는 완전히 잘못됐기 때문에 시장에서 외면당합니다. 하지만 당시에 다른 기술을 선택했던 것보다는 돈을 덜 잃을겁니다.
  • Many ideas (and their authors!) were validated positively. The MVP has proved to be interesting for the users. People wanted to pay for using it. Those ideas turned into businesses. Many of those still exist today.
  • 많은 아이디어들 (그리고 만든 사람들)은 긍정적인 결과를 얻습니다. 출시한 제품은 사용자의 관심을 끌고, 그들은 돈을 낼 의향도 있습니다. 이런 아이디어들은 비즈니스가 되고, 지금까지 살아남은 것들도 많죠.
  • As developers, we sometimes forget how much impact our work has on the world around us. All of the above wouldn’t have happened without us and Rails.
  • 개발자로 살아가며 우리가 한 일이 주변과 세상에 얼마나 영향을 주는지 잊어버릴 때가 많습니다. 위에 이야기한 것과 같은 일들은 우리 그리고 레일즈가 아니었다면 일어나지 않았을 것입니다.
  • What about those less technical people? Did they have their chance in the Rails revolution?
  • 기술 외 분야의 사람들은 어떤가요? '레일즈 혁명'에 함께 할 기회가 있었을까요?
  • Yes!
  • 물론입니다!
  • It was late 2007 when I was contacted by a potential client. He said he was a fashion designer and he needed help with Rails deployment.
  • 2007년에 한 사람을 만났는데, 그는 자신이 패션 디자이너이고 레일즈 앱을 배포하는데 도움이 필요하다고 말하더군요.
  • What?
  • 뭐라고요?
  • A fashion designer needing help with Rails deployment!
  • 한 패션 디자이너가 레일즈 앱 배포하는데 도움이 필요하다고!
  • “What do you want to deploy?”, I asked, assuming he got some technical terminology wrong. “Oh, it’s a prototype of a web application which helps men choose good clothes for them.”
  • 기술적인 용어를 잘 몰라서 그랬거니 하며 "뭘 배포하려고 하시는데요?"라고 물어봤지요. "아, 남자들이 옷을 고를 수 있게 도와주는 웹 애플리케이션의 시제품이에요."
  • I looked at it and I was speechless. It was a fully working app, with a non-trivial algorithm implemented in Ruby.
  • 들여다 보고는 할 말을 잃었습니다. 그건 제대로 동작하는데다 루비로 구현한 예사롭지 않은 알고리즘을 가지고 있었어요.
  • It was actually ready for deployment. That’s all I was needed for here. This scared me. One year before, I decided to rely my programming career on Rails. Is this what I signed up for? Non-technical people being able to implement an application needing me just for the deployment?
  • 게다가 바로 출시해도 될 정도여서, 그게 제가 할 일의 전부였어요. 심지어 무섭더군요. 불과 일 년 전에 레일즈를 저의 주된 프로그래밍 경력으로 삼기로 결정했었거든요. 내가 뭘 한거지? 일반인이 애플리케이션을 개발해 버리고 나는 배포만 해주면 되는 상황이라니!
  • I wanted to go back to my former Java world. To the world, where  my job wasn’t threatened by fashion designers!
  • 다시 자바 월드로 돌아갈까 싶었지요. 패션 디자이너가 내 직업을 넘볼 수 없는 세상 말이에요.
  • I realised that something big is happening. 
  • 뭔가 큰 일이 벌어지고 있다는 걸 깨달았어요.
  • I was lucky enough to be part of it. Rails enabled more people to be involved in creating web applications. I was very curious where it's all going to.
  • That was the time when new gems (they were called plugins at that time) started to pop up every week - acts_as_taggable, acts_as_anything, acts_as_hasselhoff (yes, there's such plugin: https://github.com/lazyatom/acts_as_hasselhoff/ ).
  • The fashion projects ended very well. When the client understood that I'm faster than him in developing the features, he took care of marketing and other stuff. I wasn't just the deployment person anymore.
  • Creating new Rails projects in 2008 was like combining little pieces together. 
  • At the beginning it was fun. However, the whole new wave of Rails developers started creating new versions of their gems every week. Each version had different dependencies. The authentication libraries kept changing every month at that time. At some point, it wasn't just connecting the pieces, but also hard work on untangling the dependencies to make it all work together.
  • The Rails Way was born
  • This concept was never clearly defined. It was a term to describe the Rails approach.
  • It's worth noting that at that time, everyone in Rails was coming from somewhere. I was from the Java world. Some people came from the PHP world. There were even some ex-Microsoft people.
  • At that time there were no developers who "were born with Rails".
  • When The Rails Way concept was appearing it was a way of distinguishing it from "the architecture astronauts Java way" or the "PHP spaghetti way". We needed to be unique and have something to unite us.
  • Most of our community DNA was very good, but there was also something negative. A big part of the Rails community was united with the anti-Java slogans. Everything Java-like was rejected. XML? No, thank you, we've got yaml. Patterns? No, thanks.
  • As a community, we entirely skipped the DDD movement, which took over the Java and .NET worlds.
  • "We don't need this"
  • "We've got ActiveRecord. We take the object from the database row and use it in all the three layers. Fat models or fat controllers? Whatever, let's just not create new layers."
  • This way of thinking became more popular.
  • The Rails Way was very successful
  • A new generation of developers started to appear. They were the ones who were born with Rails. Ruby was their first language. Rails was their first framework. The didn't bring the baggage of Java or PHP past life.
  • They joined the Rails community and embraced what was presented to them. That was The Rails Way.
  • What is The Rails Way?
  • It's hard to define it easily. I tried to do it recently and I found a few features that make it so uniq:
  • - ActiveRecord objects everywhere, including the views
  • - External gems used for most of the features
  • - Non-trivial logic implemented with the combination of filters, callbacks, validations, state-machine - often in a non-easy-to-follow-way.
  • - Magic - Convention over Configuration, DRY, metaprogramming
  • - Only 3 layers - Models, Views, Controllers
  • When is The Rails Way good?
  • It's really good for developers who start their career. I keep teaching The Rails Way to the students - at the beginning. That's the most efficient way to get a result. It's the best way to stay motivated while learning more.
  • Within a project, The Rails Way is great at the beginning, when you're still not sure, where you go with the features and you need to experiment. In different project, the meaning of the beginning may be different. In some projects, I see the need to get out of the Rails Way as soon as the second month of development starts. In other projects it may be a year.
  • When is The Rails Way not enough?
  • When you start wondering - does that code belong to the model or to the controller - it's a sign that you may be looking for something more than the Rails Way.
  • When it's not clear how a feature works, because it's MAGIC - it's a sign the code controls you, not the other way round. You need something more to turn the magic into an explicit code.
  • When you start creating model classes which don't inherit from ActiveRecord::Base and you have problems explaining to the team, why you needed that.
  • When you try to test, but it either takes ages, because you need full integration tests, or you die by over-mocking.
  • When you try to switch to a hosted CI, but they are unable to run your test suite.
  • When you can only migrate data at nights, because the migrations lock the tables.
  • Learning from mistakes
  • I've had the "luck" to review hundreds of Rails projects over the last 10 years. The same patterns were visible over and over again. An app was in quick development for the first months and then it started stagnating to the point where no one was happy with the speed.
  • I've started collecting those patterns. I grouped them into code smells, anti-patterns, magic tricks.
  • Alternative architectures
  • Meanwhile, over the years, I was studying many non-Rails-Way architectures like DCI, DDD, CQRS, Hexagonal.
  • Then I started to draw lines between those two.
  • How can I get from the Rails code smells into DDD?
  • Does DCI make sense in Rails apps?
  • Is there place for the Hexagonal adapters?
  • What are the aggregates in a Rails app?
  • Ruby and Rails are very unique and specific. Some things fit well into it, while others seem foreign to the way we write code.
  • From A to Z
  • I picked some of the building blocks of the architectures and tried to apply them in the Rails projects. The ones that didn't fit, I rejected. At the end, I only kept the ones which looked helpful for the typical problems.
  • This was just the beginning. Even if you know the starting problem (point A) and you know the end result (point Z), there's many steps in between that need to be made very carefully.
  • Safety of changes
  • I assumed the code transformations will be done on production applications. No place for any risk here. Some of the changes may even be applied to untested code.
  • Your application needs to be safe, even when you apply the changes. Your boss and your clients will never allow introducing any bug "because I was improving the architecture". It's just not acceptable.
  • Working on the recipes
  • It took me over a year to put together the refactoring recipes. Your code contains lots of small issues which make it harder to introduce a better design.
  • You won't introduce service objects if your controllers are filters-heavy. The dependencies will break your code.
  • You won't introduce service objects, if your views rely on @ivars magic. You need to be explicit with what you're passing to the views.
  • You won't make the build faster if it the tests still hit the database. You won't get rid of the real database as long as your ActiveRecord classes contain any logic. You need to introduce repository objects.
  • You won't introduce service objects easily, if your controller action can do different things, depending on the params (params[:action] anyone?). You need to use the routing constraints.
  • You won't find any shortcut, unless you know the SimpleDelegator trick which helps you move a lot of code into a temporary service object at once.
  • Those are some of the things I was working on. Those recipes are tested in big Rails projects by many different teams.
  • Those recipes work.
  • They will make your architecture improvement easier.
  • The book
  • This all led to me to writing the "Fearless Refactoring: Rails Controllers"book.
  • The core of the book are recipes. However, the recipes alone may leave you with just the mechanics, so we've added many chapters which explain the techniques in details.
  • We've also added the "Big examples" chapters. They take you through some (ugly) code and apply the recipes, one by one.
  • Thanks to all of you who bought the book when it was still beta since February (more than 200 of you!), I'm very confident about its quality. You sent me a great feedback. You sent me the before/after pieces of code. This book wouldn't happen without the people who trusted us so early. Thank you!
  • 1.0 release
  • Some of you prefer to read books only when they are completed. Now is the best time to get it.
  • On Monday, December 1st, the book goes 1.0, yay! During the next days we still keep the discounted price: $35. On Monday, the price goes up to its final price ($49). On Monday, you'll receive the 1.0 book update, no matter when you bought it.
  • If you already bought the book - could you please consider recommending it to your friends? Just forwarding this email should do the job.
  • Thank you so much!
  • Andrzej Krzywda
0 Comments