Прийшов час попрощатися з Rails

В минулому році я прийняв рішення, що не буду більше використовувати Rails, і не буду підтримувати Rails у своїх гемах. Крім того, я буду робити все можливе, щоб мені ніколи не довелося знову зіткнутися з Rails на роботі.
Так як я залучений в безліч Ruby-проектів, люди часто запитують мене, чому я не люблю Rails, які проблеми у мене є з ним і так далі. Тому я вирішив написати цей довгий пост, щоб підвести підсумки і все пояснити.
Стаття частково технічна, частково особиста і, на жаль, частково гнівна. Я пишу це не для того, щоб привернути увагу, отримати відвідувачів і т. п., у мене немає жодного інтересу в цьому. Я пишу це, тому що я хочу закінчити мої дискусії про Rails і щоб було місце, куди давати посилання кожен раз, коли я чую одні й ті ж питання.
Я також хотів би розповісти вам декілька історій, які "початківці Rails-розробники", ймовірно, ніколи не чули, і висвітлити деякі питання, які є досить важливими, щоб принаймні, подумати про них.
Добра частина
Я не буду робити вигляд, що все в Rails погано, неправильно, і фреймворк є втіленням зла. Це було б не справедливо, та й просто нерозумно. Про Rails можна сказати дуже багато хорошого. І я згадаю пару (очевидних?) речей для підтримки балансу.
Отже, Rails зробив Ruby популярним. Це факт. Я став Ruby-розробником, що в свою чергу змінило мою кар'єру і дало мені багато дивовижних можливостей, саме завдяки Rails. Багато рубисты тих днів пройшли по тому ж шляху. Ми всі тут завдяки Rails. У багатьох випадках, Rails насправді зробив величезний вплив на людей, і буквально покращив їм життя. Люди отримали кращі робочі місця, кращі можливості та хороші гроші. Це було радикальною зміною умов "ігри" для багатьох з нас.
протягом багатьох років Rails & DHH надихнули багатьох людей, в тому числі людей з інших спільнот, на переосмислення того, що вони роблять. Наприклад, я впевнений, що Rails сприяло поліпшенню PHP співтовариства (ви можете спробувати довести, що я помиляюся, але у мене є досить яскраві спогади як Symphony дізнався купу натхнення від Rails). Те ж саме відбулося в Java, фреймворк Play є прикладом.
Є й інші фантастичні аспекти. Rails був завжди націлений на простоту використання і можливість швидко створювати веб-додатки, що дозволило досягти успіху таким ініціативам, як Rails Girls. Rails довів людям, що вони здатні створити щось самостійно, без будь-якого досвіду програмування, у відносно короткий проміжок часу. Це дивно, так як це легко може стати воротами у світ програмування для людей, які в іншому випадку навіть не розглядали можливість стати програмістом.
Моя подорож
Дозвольте мені розповісти вам трохи про моє бекграунді і як я прийшов до Rails.
Я почав працювати з Ruby в кінці 2006 року, оскільки моя дипломна робота була про Rails. Я вивчав мову в той час, як писав свій диплом. Це було весело, це було цікаво, це було щось нове для мене. Тоді я ще працював в якості PHP розробника. І як типовий PHP-програміст в ~2005-6, я робив всі ці типові речі: писав SQL-запити в шаблонах уявлень, писав у процедурному стилі, а потім розробляв свій власний фреймворк і свій власний ORM, розчаровувався і вигоряв. Незважаючи на деякі знання C, C++, Java і Python, я вирішив перейти на Ruby, з-за Rails. Я вибрав їх для свого диплома і зовсім випадково натрапив на пропозицію про роботу від місцевого магазину на Rails. Я відповів і вони найняли мене. Це було в березні 2007 року.
Отже, з березня 2007 року я почав працювати з Ruby професійно, і де-то з 2009 я почав вносити внесок у OSS проекти на Ruby. З тих пір я працював у консалтинговій компанії протягом 3.5 років, в основному c великими і складними проектами. Потім працював фрілансером протягом декількох років, працював з купою клієнтів, відкрив свою власну компанію, а потім повернувся на повний робочий день, а потім знову на фріланс, і тепер я знову штатний співробітник. Я створював Rails-додатки «з нуля», і брав участь у розробці щодо великих Rails-додатків.
Дозвольте мені розповісти вам одну історію. Одного разу я приєднався до існуючого проекту. Це було огрооомное додаток, яке управляло веб-сайтой торгового он-лайн спільноти. Складні моделі продажів, складні промо-акції, вигадливі конфігурації продукту, купони, групи користувачів, повідомлення — в ньому було все це. Я приєднався до них, щоб допомогти додати кілька нових фіч. Однією з моїх перших завдань було… додати посилання на те, що на якійсь сторінці. Мені знадобилося кілька днів, щоб додати цю дурну посилання. Чому? Додаток було великим кулею складної логіки предметної області, розкатаним з кількох шарів і з настільки складними вьюхами, що було не просто навіть знайти потрібний шаблон, в якому додати посилання. Так як мені потрібні були деякі дані замовлення для того, щоб створити цю посилання, не було очевидно, як я повинен отримати його. Нестача внутрішніх API додатка і опора виключно на ActiveRecord зробили це завдання надзвичайно важким. Я не жартую.
Мої перші фрустрації з Rails почалися доволі рано. Я став незадоволений ActiveRecord приблизно після 6 місяців його використання. Також мені ніколи не подобалося, як Rails підійшов до роботи з JavaScript і AJAX. У разі, якщо ви не пам'ятаєте, чи не застали версії до того, як Rails прийняв UJS підхід (який був хітом обговорень в 2007-2008 роках), Rails використовував inline Javascript в шаблонах, породжений зв'язкою противних хелпери. Як і всі з Rails, це було "легко і приємно на початку", а потім перетворювалося в непідтримувану лайно. Зрештою, Rails прийняв UJS у версії 3.0 і, здається, співтовариство погодилося, що це найкращий підхід. Це було, коли Merb був убитий злиттям з Rails. О, ви не знаєте, що таке Merb? Добре, давайте поговоримо про це.
Чому я був захоплений Merb & DataMapper
Merb був проект, створений Ezra Zygmuntowicz. Він почався як хак, щоб зробити завантаження файлів швидше і потокобезопасной. І він пройшов цікавий шлях від цього хака до модульного, потокобезопасного, швидкого full-stack фреймворку для розробки веб-додатків. Я пам'ятаю, як люди почали говорити про Merb в 2008-му і це було дивне відчуття, що відбувається щось нове, і це буде здорово!
Ви зраділи, коли в Rails з'явився режим "API", чи не так? Хм, а Merb мав 3 режими: режим повного стека, режим API і мікро-режим, у якому він був спрощений до мінімуму, і я до сих пір пам'ятаю, що це було найшвидшою річчю коли-небудь існувала в Ruby світі. Це було 7 років тому. Вдумайтеся в це.
У той же час ще один проект привернув увагу спільноти — DataMapper. Він став частиною Merb стека, будучи його вибором для ORM. Я був дуже збуджений тим, як він вирішував багато проблем, які були в ActiveRecord. DataMapper ще в ~2008-9 вже мав визначення атрибутів в моделях, користувацькі типи, ледачі запити, більш потужний DSL запитів і так далі. У 2008 році Yehuda Katz був одним із Core-розробників проекту, він активно просував його, був великий ажіотаж з цього приводу. DataMapper в кінцевому рахунку був кращим ORM, ніж ActiveRecord в 2008-9. Було б несправедливо не згадати про те, що Sequel з'явився приблизно в той же час і досі використовується набагато менше, ніж ActiveRecord, незважаючи на те, що є більш гарним рішенням.
Я був захоплений Merb і DataMapper так, як вони принесли надію, що ми можемо зробити щось краще і створити здорову конкуренцію для Rails. Я був схвильований, тому що обидва проекти заохочували модульний підхід і потокобезопасность, не кажучи вже про такі речі, як просто хороші стандарти написання коду.
Обидва проекти були зрештою вбиті Rails, так як Merb був "вліт" в Rails, що вилилася у величезний рефакторинг Rails для версії 3.0. DataMapper втратив увагу спільноти і без особливої підтримки не зміг розвиватися, як це могло б бути, якщо Merb не був би "вліт" в Rails.
З цим рішенням екосистема Ruby втратила купу важливих проектів і тільки Rails виграли від цього. Є рішення вбити Merb було хорошим чи ні, це питання особистої думки, ми можемо тільки припускати, що могло б статися, якщо рішення не було прийнято. Тим не менш, є проста істина про конкуренції — це здорово. Відсутність конкуренції означає монополію, і є проста істина про монополії — це не здорово. Конкуренція сприяє прогресу та інновацій, конкуренція створює здорову екосистему, вона дозволяє людям співпрацювати більше, щоб поділитися тим, що поширене, щоб створювати кращий фундамент. Це не те, що відбувається в співтоваристві Ruby.
Після того, як Merb & DataMapper були практично знищені (у довгостроковій перспективі), створити щось нове в екосистемі Ruby виявилося вкрай складно. Оскільки увагу людей сфокусовано на Rails, нові проекти були під його сильним впливом. Прорватися з новими ідеями було важко, якщо не сказати більше… так як кожен раз, коли ви демонструєте, люди просто хочуть, щоб це було схоже на Rails і добре працювало з Rails. Робити проекти, які працюють з Rails, — важко, але я повернуся до цього питання пізніше.
Після всіх цих років ми в кінцевому підсумку прийшли до одного фреймворку, подчиняющему всю нашу екосистему, впливаючи на тисячі розробників і створення стандартів, які… вельми спірні. Ми втратили різноманітність екосистеми, яка почала рости в 2008 році і була пригнічена Rails.
Гей, я знаю, як це звучить майже як теорії змови, але не ставтеся до цього так. Те, що я сказав тут, — це факти з домішкою моїх особистих почуттів. Я почав брати участь у DataMapper в кінці 2009 року і бачити як він руйнується було дуже сумно.
Складність!
Складність є нашим найбільшим ворогом. Люди стали проявляти менше ентузіазму до Rails, оскільки швидко виявилося, що маючи справу із зростаючою складністю, він залишає нас з великою кількістю запитань без відповіді. Те, що пропонують DHH & co. ніколи не було достатньо, щоб вирішити багато проблем, з якими тисячі розробників почали боротися ще в 2007-2008 рр. Деякі люди сподівалися, що, можливо, Merb/DataMapper принесуть покращення, але тепер ви знаєте, що сталося, так що ми всі повернулися назад до Rails в 2010 році, коли Rails 3.0 був випущений.
Кілька днів тому хтось запостив на /r/ruby посилання на статтю про організацію коду за допомогою "Service об'єктів". Це одна з багатьох подібних статей. Якщо ви думаєте, що це свого роду тенденція останнього времеми, погляньте на статтю James Golick від березня 2010 — "Crazy, Heretical, and Awesome: The Way I Write Rails Apps".
Ми говоримо про шляхи вдосконалення архітектури наших Rails додатків протягом приблизно 6 років. Я намагався внести свій внесок в цю дискусію, наскільки я міг — статтями, виступами на конференціях і роботою над багатьма проектами з відкритими вихідними кодами, які прагнуть вирішувати різні складні завдання.
Однак подібні аргументи та ідеї завжди висміюються членами Rails Core Team, і особливо DHH. Це було відлякуючим і шоком для мене, і це причина, чому я ніколи не намагався внести свій внесок у Rails. Я чертовски впевнений, що мої пропозиції будуть в кінцевому підсумку заминусованы. Monkey-patches? Да ладно, не проблема, ми любимо нашу 10.years.ago! Нові абстракції? Кому це потрібно, Rails — це просто! TDD? Не проблема, вона мертва, не турбуйтеся! ActiveRecord роздута — ну і що, це ж так зручно, давайте додамо більше можливостей!
Екосистема Rails, особливо навколо своєї Core Team, ніколи не справляла на мене хороше враження, і для мене не проблема визнати, що я просто боюся пропонувати будь-які зміни. Це особливо актуально, так як перше, що я хотів би запропонувати "будь Ласка, видаліть ActiveSupport" (ха-ха… уявіть собі це!).
Гаразд, давайте перейдемо до деяких технічних деталей.
Зручність-орієнтоване проектування Rails
Як я вже говорив, Rails був побудований з прицілом на зручність використання. Не плутайте це з простотою. Тільки вчора я натрапив на цей твіт, який говорить про це:
Simple vs Easy
Ось як працює Rails, класичний приклад:
User.create(params[:user])

Ви бачите просту рядок коду, і ви можете відразу сказати(якщо ви знаєте, є User моделлю ActiveRecord), що вона робить. Проблема тут полягає в тому, що люди плутають простоту зі зручністю. Цю рядок зручно/легко написати у вашому контролері і все відразу запрацює, чи не так?
Однак, цей рядок коду не є простою, її легко написати, але код "під капотом" надзвичайно складний, так як:
  • params часто повинні пройти через СУБД-специфічні приведення типів
  • params повинні бути валидированы
  • params можуть бути змінені за допомогою колбеков, включаючи потенційні виклики зовнішніх системи, викликають побічні ефекти
  • невалидное стан призводить до встановлення повідомлень про помилки, які залежать від зовнішньої системи (наприклад I18n)
  • валідні params повинні вплинути на стан об'єкта, і можливо змінити стан асоційованих з ним об'єктів
  • один об'єкт або весь граф об'єкта повинен бути збережений в базі даних
Це брак поділу ответвенности, яка завжди завдає шкоди будь-якого складного проекту. Це збільшує зв'язування(coupling) і утрудняє зміну і розширення коду.
Але в Rails світі, це не є проблемою. У Rails світі основні принципи дизайну такі як SRP (і SOLID в цілому) в висміюють і представляють як "роздуті, непотрібні абстракції, які збільшують складність". Коли ви говорите, що віддаєте перевагу моделювати варіанти використання програми, використовуючи свої власні об'єкти і робити складні частини явними, лідери Rails скажуть вам YAGNI. Коли ви говорите, що ви віддаєте перевагу використовувати композицію, яка робить код більш надійним і гнучким, лідери Rails, за винятком tenderlove, скажуть вам «use ActiveSupport::Concerns».
Для Rails-розробника це не проблема, що дані, що надходять з веб-форми направляються у глибини ActiveRecord, де Бог знає, що станеться.
Справді складна частина в цій дискусії — бути у змозі пояснити, що це першочергова проблема. Людей приваблює Rails, тому що він дає вам помилкове відчуття простоти, в той час як те, що відбувається насправді полягає в тому, що складність захована за зручними інтерфейсами. Ці інтерфейси засновані на багатьох припущень про те, як ви збираєтеся писати і проектувати вашу програму. ActiveRecord є лише одним типовим прикладом, але Rails повністю побудований на цій філософією, кожна частина Rails працює аналогічно.
Я повинен згадати, що я знаю про величезних зусиллях зробити ActiveRecord краще, таких як введення Attributes API (зроблено за допомогою серйозного внутрішнього рефакторінгу, який поліпшив кодову базу). На жаль, до тих пір, поки ActiveRecord поставляється з більш ніж 200 публічними методами і заохочує використання колбеков і concerns, це завжди буде ORM, яка не в змозі впоратися із зростаючою складністю.
чи Зміниться ця філософія в Rails? Я так не думаю. У нас немає ніяких ознак того, що щось покращиться в цьому відношенні, так як лідери Rails просто проти цього. Просте доказ — недавнє спірне додаток
ActiveRecord.suppress
, яке було запропоновано самим DHH. Зверніть увагу на те, як він в черговий раз жартує над звичайними Ruby класами, кажучи: "Так, ви можете добитися того ж, створивши окрему фабрику CreateCommentWithNotificationsFactory". Ну-ну!
ActiveCoupling
Повинен Rails вашим додатком? Це був важливий питання, яке задають багато хто після перегляду виступу дядечка Боба, де він в основному пропонує більш сильне розділення між веб-частиною і вашим основним додатком. Відкинувши технічні деталі, це гарна порада, але Rails не був розроблений з урахуванням цього факту. Якщо ви робите це з Rails, ви втрачаєте всю суть цього фреймворку. За фактом, погляньте на те, що сказав DHH про це:
Rails is your app
Його думки на цей рахунок гранично ясні, чи не так? Важливою частиною є "звичайно, є". І знаєте, що? Я повністю згоден!
Rails є вашим додатком, і завжди так буде, доки ви не докладаєте великі зусилля, щоб використовувати його таким чином, для якого цей фреймворк не був призначений.
Подумайте про це:
  • ActiveRecord покликаний стати центральною частиною логіки вашої предметної області. Ось чому він надає гігантський інтерфейс з великою кількістю функцій. Ви можете іноді отримувати частину логіки в окремі компоненти, коли це має сенс, але Rails філософія полягає в тому, щоб помістити все в ActiveRecord, а не турбуватися про SRP, не турбуватися про LoD, не турбуватися про тісний зв'язок між логікою предметної області і шаром збереження і так далі. Ось як ви можете ефективно використовувати Rails.
  • Весь "шар" подання в Rails пов'язаний з ActiveModel, і як наслідок він связян і з Active Record ORM (це може бути і Продовженням, але це не має значення)
  • Контролери є невід'ємною частиною Rails-додатки, і сильна зв'язаність має місце і тут
  • Хелпери також є невід'ємною частиною Rails-додатки, сильна зв'язність ще раз
  • Все в Rails, і в безлічі сторонніх gems, створених для Rails, відбувається через наслідування (або mixins, або на базі класів). Rails і сторонні gems зазвичай не надають автономних, повторно використовуваних об'єктів, вони надають абстракції, від яких походять ваші об'єкти — це ще одна форма сильної зв'язності.
Маючи це на увазі, було б божевіллям вважати, що Rails — не ваш додаток. Якщо ви намагаєтеся уникнути цього типу зв'язності, можна собі уявити, які зусилля доведеться докласти і скільки з вбудованою функціональності ви втратите. І саме тому демонстрація альтернативних підходів в Rails створюють враження роздутих, непотрібних абстракцій, що нагадують людям про їх "страшних" Java днями. Rails не був побудований з орієнтацією на низьку зв'язність і компонентно-орієнтований дизайн.
Не боріться з цим. Прийміть це.
Небажана частина
Незважаючи на все вищесказане, моя найбільша скарга на Rails — це ActiveSupport. Так як я вже писав про це, я не відчуваю, що мені потрібно повторюватися. Я також рекомендую почитати коментарі в тій статті.
Єдине, що я хотів би додати, що саме з-за ActiveSupport, я не вважаю Rails бажаною частиною екосистеми Ruby. Ця бібліотека є квінтесенцією всього неправильного в Rails для мене. Відсутність фактичних рішень, відсутність чітких абстракцій, просто купа воркэраундов для вирішення проблеми під рукою, воркэраунды, які перетворені на офіційний API, і карго-культ в результаті. Чудово!
Rails є закритою екосистемою, і це накладає погані вимоги на інші проекти. Якщо ви хочете змусити працювати з Rails, ви повинні подбати про такі речі, як працездатність при підключеному ActiveSupport, або що нічого не зламається від звірячої перезавантаження коду в режимі розробки, або що об'єкти надаються глобально, тому що, ну ви знаєте, в Rails все повинно бути доступно скрізь, для вашої зручності.
Те, як працює Rails, вимагає багато додаткових зусиль від розробників, що створюють свої геми. Перш за все, слід очікувати, що ваші геми можуть працювати з Rails (бо, очевидно, всі будуть використовувати їх з Rails), і це саме по собі є непростим завданням. У вас є бібліотека, яка працює з базами даних, і ви хочете змусити її працювати з Rails? Ну ось, тепер ви повинні змусити її працювати, як ActiveRecord, більше або менше, оскільки інтерфейс інтеграції — ActiveModel, спочатку заснований на ActiveRecord часів Rails 3.0.
Є безліч обмежень, які роблять інтеграцію з Rails досить важким завданням.
Ви поняття не маєте, зі скількома проблемами ви можете зіткнутися при спробі змусити код працювати з гарячою перезавантаженням коду в режимі розробки. Rails очікує глобальну, змінювану середовище виконання. Для того, щоб зробити все ще важче, вони ввели Spring. Цей гем відкриває цілу категорію потенційних нових багів, з якими ваші геми можуть зіткнутися, коли ви намагаєтеся змусити їх працювати з Rails. Я настільки завагався з цим, друзі мої, що мені більше нічого сказати. Мало того, що перевантаження коду Ruby працює ненадійно, так це до того ж додає купу абсолютно непотрібною складності для наших гемов і додатків. Це впливає на всіх, хто розробляє геми, які повинні працювати з Rails. Ніхто з команди ядра Rails, незважаючи на критику на протязі багатьох років, навіть не думав, що було б гарною ідеєю, подивитися, як це можна було б зробити краще. Якщо б хто-небудь просто зосередився на підвищення швидкості завантаження програми, ми могли б покластися просто на перезапуск процесу. Крім того, ви дійсно повинні використовувати автоматизоване тестування, щоб впевнитися, що зміна, яку ви тільки що зробили насправді працює, а не тиснути F5. Просто до вашого відома.
Я знаю, це звучить, як-ніби я скаржуся, хоча по суті так і є! Я намагався підтримувати Rails і це було дуже розчаровує досвідом для мене. Я здався, я не хочу робити це більше.
Оскільки моє рішення проблем передбачало видирання ActiveSupport, видалення ActiveRecord і додавання нормального шару представлення, який би був відділений від будь-якого ORM, я зрозумів, що нерозумно думати, що це коли-небудь відбудеться в Rails.
Відхід від Rails
В результаті 9 грьобаних років роботи з Rails і активної роботи над багатьма проектами OpenSource на Ruby, я здався. Я більше не вірю, що щось хороше може трапитися з Rails. Це моя особиста точка зору, але багато люди поділяють ті ж самі почуття. У той же час, є багато інших, які щасливі з Rails. Радий за них! Чесно! Rails увійшов у загальне вживання, у нього є свої варіанти використання, він як і раніше допомагає людям і це зрілий, добре підтримуваний стабільний веб-фреймворк. Я не намагаюся переконати кого-небудь, що Rails в кінцевому рахунку поганий! Він просто дуже поганий для мене.
Впрочему це мало свої наслідки. Саме тому я виявився залучений в такі проекти, як dry-rb, hanami and trailblazer і тому я давно працюю над rom-rb. Я хочу допомогти побудувати нову екосистему, яка, ми сподіваємося, поверне той самий ентузіазм, який ми всі відчували в часи Merb і DataMapper.
Нам потрібна різноманітна екосистема, нам потрібно більше маленьких, цілеспрямованих, простих і надійних бібліотек. Нам потрібні рубисты, які відчувають себе комфортно, використовуючи фреймворки спільно з невеликими бібліотеками.
Відхід від Ruby
Правда в тому, що відхід від Rails — також початок мого наступного подорожі — відхід від Ruby в якості основного мови. Я надихнувся функціональним програмуванням в останні пару років. Ви можете бачити, що в цьому стилі я пишу тепер і на Ruby. Я спостерігаю за зростанням Elixir з великим піднесенням. Я також вивчаю Clojure, який в даний момент знаходиться на вершині мого списку "мови для вивчення". Чим більше я дізнаюся, тим більше я люблю його. Моя кінцева мета полягає в тому, щоб вивчити ще й Haskell, оскільки я заінтригований його статичної типізацією. В даний час на роботі, я працюю з Scala. Я зміг дуже швидко оцінити переваги статичної типізації в ньому, незважаючи на те, що це була жорстка перебудова мого робочого процесу розробки, включаючи компіляцію і TypeError помилки. Це освежий досвід — бачити, як мій редактор каже мені, що я зробив помилку, перш ніж я добрався до виконання будь-яких тестів.
Чим більше я поринаю в функціональне програмування, тим більше я бачу, наскільки відстає Rails, коли справа доходить до сучасного дизайну додатків. Monkey-patching, опора на глобальне змінюване стан, складний ORM, ці речі розглядаються в якості основних проблем функціональних мовах.
Я знаю, багато хто скаже "але Ruby є об'єктно-орієнтованою мовою, використовуй це на свою користь, замість того, щоб намагатися зробити з нього те, чим він не може бути". Але це не так. Насамперед, Ruby є об'єктно-орієнтованим мову з функціональними особливостями (блоки, лямбды тощо). По-друге, уникнення змінюваного стану є загальним, доброю порадою, який ви можете застосувати у своєму Ruby-коді. Усунення глобального стану та ізолювання його, коли ви не можете його уникнути, — також дуже хороший загальний рада.
Як би там не було, я покидаю Ruby. Я вже почав цей процес. Він займе роки, але це моє напрямок. Я буду продовжувати працювати і підтримувати rom-rb, dry-rb, допомагати з hanami і trailblazer, так що не хвилюйтеся, ці проекти дуже важливі для мене, і я щасливий спостерігати зростання їх спільнот.
Найбільш часта зворотній зв'язок
Це список заздалегідь підготовлений список зворотного зв'язку і питань, але він заснований на реальній зворотного зв'язку, яку я отримував.
Писок. Rails чудовий і працює дуже добре для мене.
Це є найбільш поширеним варіантом зворотного зв'язку, яку я отримую. Насамперед, мене турбує, що багато люди так реагують. Ми обговорюємо інструмент, а не людини, немає необхідності сприймати це так емоційно. Не зрозумійте мене неправильно, я розумію, що це природно "захищати" щось, що допомогло вам, або те, що вам просто подобається, в той же час здорово бути в змозі думати за межами коробки і бути відкритим, щоб почути критику і просто подумати про це. Якщо ви щасливі з Rails, це здорово, насправді.
Ти просто скаржишся, ти не допомагаєш, ти нічого не зробив, щоб допомогти Rails стати краще, ти не запропонував жодних рішень описаних проблем
Цей тип зворотного зв'язку раніше мене дуже злив і засмучував. В момент написання цього і згідно з GitHub, я зробив 2435 комітів у OSS минулому році. Це було в мій вільний час. Так, я не сприяв безпосередньо Rails, з причин, які я пояснив в цій статті. Там занадто багато того, з чим я не згоден і це було б марною тратою часу для обох сторін. Я вносив свій внесок через пости в блогах, доповіді на конференціях і тисячі рядків OpenSource коду, які ви можете знайти на GitHub.
Це OSS, просто форкни Rails
Це абсолютно повз каси. Нам необхідно різноманітність в екосистемі із хорошим вибором бібліотек, а також кілька фреймворків з їх унікальним набором функцій, які роблять їх придатними для різних варіантів використання. Форк Rails не буде мати ніякого сенсу. Ніхто не буде форкать Rails, щоб пройти через такі випробування, як видалення ActiveSupport і усунення високою зв'язності від таких концептів як ActiveRecord і т. д. Простіше і швидше створити щось нове, що інші люди вже роблять (див. Hanami).
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.