Понякога чувам хората да се оплакват от своите клиенти, казвайки, че те настояват при използването на Rails, че са имали твърде много Kool Aid. Ако са вербовчици, почти им става гадно в стомаха, че трябва да намерят още един разработчик на Ruby on Rails ‘primadona’. След това те изваждат нещо подобно на този удивително невеж сравнение между Git и PHP за да докажат своята теза. „Те дори не знаят какво искат“, казват те.
За нас като програмисти , понякога наистина изглежда, че нашите клиенти нямат представа. Обичаме да преувеличаваме случаи като този. Когато се замислите малко, не изглежда правилно да мислите, че човек, който ми дава пари за изграждане на нещата, е някак ограничен и „просто не го разбира“. Всъщност, Вярвам, че повечето клиенти добре познават възможностите си и въпреки това те все още реши да тръгне с Rails.
Ще се опитам да обясня какво, според мен, прави Rails достатъчно полезен, за да бъде разгледан сериозно за множество проекти и нужди.
какво е bootstrap файл
Възможно е никой дори да не знае за предимствата на Ruby, ако не беше самата Rails. Някои хора обичат да омаловажават Руби, като казват, че е „толкова лесно за Руби“ с нейния „рицар в блестяща броня, наречена Rails“ и че без Rails, „Ruby би било без значение“. Не мога да кажа със сигурност дали това е вярно или не, но знам, че би било голям срам, ако светът пропусне такъв превъзходен език. Факт е: авторът на Rails съзнателно избра Руби и неговият „див“ залог се изплати с огромен интерес. Това, което той видя тогава, много други могат да видят и днес. Ruby по някакъв начин дава възможност на програмистите по специален начин, който е толкова трудно да се обясни на „немитите маси“. И така, защо да използваме Ruby on Rails? Ruby прави програмистите щастливи, както се рекламира.
Докато повечето разработчици се съгласяват, че Ruby е удобен, някои го виждат като твърде много така. Те се притесняват какво може да се случи с всички свободи, които Руби позволява, и с целия потенциал за злоупотреба. Позволете ми да илюстрирам с някои маймунски кръпки:
'1'.to_i #=> 1 class String def to_i raise 'foobar' end end '1'.to_i #=> RuntimeError: foobar Толкова е лесно: само с пет реда код сме взели съществуващ клас и сме заменили поведението му. Нохтинг е свещено - дори струна. Тази конкретна грешка би била лесна за откриване, но нещата могат да станат много по-зловещи:
class String def to_i self.to_f - 1.13 end end '2'.to_i #=> 0.8700000000000001 Точно така, ние въведохме грешка в класа String, която може да бъде обвита и скрита от слой върху слой на сложност.
Така че, може би си мислите: Могат ли всички и майка им да объркат скъпоценната ми молба? Въпреки че това поведение наистина изглежда страшно - наистина не е така. След пет години на използвайки Ruby , Имах точно нула проблеми с това поведение. Може да изглежда неинтуитивно, но отново, така е и шофирането на автомобили със скорост 60 MPH в противоположни посоки, разделени само с тънка бяла линия в средата на пътя. На практика и двете работят изключително добре.
Друго предимство е, че Ruby е гъвкав инструмент. Като такъв той има остри ръбове, подобни на нож. Харесва ми да мисля, че възрастните могат да се справят добре с ножове - защитата на децата е предназначена за деца ( Tweet ). И ако се отнасяте към тях като към дете в ИТ, вие оставате жертва на Пол Греъм Парадокс на Blub : мислите, че сте по-добре без определени функции, които не разбирате или че някой ви е казал, че сте твърде опасни. Разбира се, днес се питаме „защо да използваме Ruby on Rails“; по този начин това е дебат за друг път. Разбира се, Ruby пропуска някои функции, които имат другите езици (Lisp хмм, хмм). Всичко на всичко, Ruby е близо до върха на „континуума на езиковата мощност“.
Първите ми няколко години с Руби бяха смирени. Научих толкова много само от четене на кода на другите. Понякога бях изумен; понякога бях луд; но в крайна сметка тези знания ми позволиха да общувам с компютъра си много по-ефективно от преди. Почти съжалявам за някои други „бюрократични“ езици, които ви карат да прескачате обръчи само заради прескачането им, като същевременно ви казвам „Просто правя това, което е най-доброто за вас, това е за ваше добро!“
Има дълбоко уважение към прагматизма, изплетен в ДНК на Rails на възможно най-ниското ниво. В комбинация с предимствата на Ruby, този прагматизъм създава елегантни решения и насърчава / вдъхновява Общност за разработка на Ruby on Rails да направи същото. Прагматизмът често се рекламира като палатка на релси, така че това твърдение не е ново, но напомних за това, че е истинност съвсем наскоро, тъй като един мой приятел се опита да ми покаже колко „готин“ Хибернация наистина е така. Той се мъчеше. Усещах болката му, тъй като той не беше в състояние да зададе безброй опции и конфигурационни параметри, които на първо място трябваше да бъдат стандартни рамки.
как да използвам junit в intellij
С възрастта стандартите ми за изкуствена сложност стават все по-високи и по-високи. Като се има предвид, че започнах да пиша производствен код още през 1989 г. на 11-годишна възраст (започвайки с проект за съседката ми в Clipper Summer ‘87 ), Имам близка до нулева толерантност към ненужни усложнения. И Рейлс постигна много високи резултати в този отдел. Това е нещо повече от „конвенция за конфигурация“; Говоря за цялото прагматично мислене, което е високо ценено вътре и прониква през общността на Rails.
Rails е възможно най-близо до английския (освен ако не използвате COBOL). Той използва това, което е известно като вътрешно DSL , разширявайки Ruby със собствена семантика. Изграждането на DSL винаги е опасно, тъй като ефективно разработвате нов език. Тъй като е вътрешен, не е нужно да използвате външен парсер, но в известен смисъл той се чувства като нов език. Екипът на Rails постигна добър баланс със своя DSL, използвайки го там, където има смисъл, и рядко прекалява, демонстрирайки отличен самоконтрол. Мисля, че всеки програмист, независимо от опита на Rails (и дори някои програмисти) може да разбере това:
class User true acts_as_taggable acts_as_taggable_on :certificates, :expertise_kinds validates_presence_of :first_name, :last_name, :email has_many :translations has_attached_file :avatar, :styles => {:small => '240x240>'} has_attached_file :cv ... Всъщност, ако не сте запознати с Ruby, това може да изглежда странно - сякаш не е език за програмиране. След като осъзнаете, че това са само извиквания на методи без скоби, можете да започнете. И все пак Rails DSL се чувства като този специален език за описване на изисквания, докато всъщност това е просто интелигентно именуване и присъщо използване на отличния синтаксис на Ruby.
Rails има армия от ангажиращи се, които се грижат тя да остане в най-доброто състояние. Много проекти угасват с възрастта, но при Rails искрите все още летят, когато трябва да се вземат решения. Изглежда, че поддържащите (все още) наистина се грижат и искат хората да използват Ruby on Rails и да разберат предимствата му.
Много проекти угасват с възрастта, но при Rails искрите все още летят, когато трябва да се вземат решения. TweetПод самата Rails, като череша отгоре, стои Ruby със страхотния си мениджър на пакети, RubyGems , сравним с CPAN по отношение на броя на пакетите - и като се има предвид възрастта на CPAN, това твърдение е (меко казано) много впечатляващо. Rails имаше кратък дерайл, когато се опита да направи свои собствени „Rails плъгини“. За щастие, това не се придържа, така че RubyGems остава единният, превъзходен източник за код, програмиран от много ярки хора.
мерки за ценова еластичност на търсенето __________
Синергията между страхотен език, прагматична уеб рамка и превъзходна общност дава резултат на Rails много по-добре от сумата на неговите части.
Rails е около блока. По някакъв хипстърски начин вече дори не е толкова готино. Това е хубаво при избора на технологичен стек: искате нещо доказано. И Rails е точно това. Наскоро написахме парче, говорещо за голямото разнообразие от Руби интерпретатори и времетраене които вече са налични.
Знам, знам. Като ИТ професионалист наистина трябва да ценя ‘Сериозен’ нещата и игнорирайте ‘Блясък’ . Може да изглежда плитко, но нека се изправим пред него:
Тук дори не става дума за суета; става въпрос за ангажиране на колкото се може повече умни хора, за да влеят вода в мелницата. Когато се разглеждат рамки, най-доброто място да бъдеш в тълпата. Изборът на рамка, върху която тези интелигентни хора се фокусират, просто означава, че за вас вече е покрито много повече място. И това ме отвежда до следващата ми точка.
Имам меко място за малки рамки. Харесва ми, когато мога да разбера какво прави определена рамка и защо. В този смисъл Rails е донякъде подут и дори преобладаващ на моменти.
Дилемата тук: колко пъти искате да пишете едни и същи неща отново и отново? Сигурен съм, че някои от тях могат да бъдат пренаписани по-добре, но отнема време - много време. Колкото повече позволявате на Rails да направи за вас, толкова по-малко трябва да се притеснявате за пренаписване или повторно внедряване на вашата функционалност.
Rails е (както се казва) „батерии включени“. Това не е добро нещо, ако държите на оскъдността или ако изпитвате нужда да имате задълбочени познания за това как всичко работи. На практика, ако се освободите от страховете си, изглежда работи. Rails има разумни стойности по подразбиране за почти всичко, от което се нуждаете, и е достатъчно модулен, за да избегне да ви завие в трудно място.
Запитайте се отново, защо да използвате Рубин на релси ? Rails е подходящ както за съвременни публични уебсайтове, които се конкурират с JavaScript приложения на Single Page, така и за сложни корпоративни системни приложения, които обикновено изглеждат малко по-грозни (с по-общ потребителски интерфейс с по-ниска точност), но компенсират това дефект с тон сложни бизнес правила и логика. Предимството му е, че е гъвкав и може да се конкурира както с лъскавите, така и с мощните.
node js rest api удостоверяване
За повечето често срещани проблеми Rails има компонент на ваше разположение, почти веднага, с документация, която е постоянно над средното ниво (по някакъв начин основният екип на Rails убеждава участниците, че писането на документация е страхотно (въпреки че всички знаем, че е не), което води до добре написани, кратки и спестяващи време документи).
Когато оставите настрана еднорозите и прегръдките в петък, се оказвате с мощна рамка, която можете да използвате както за бъдещия си играч, така и за следващия бизнес сайт от средата на пътя. А с вашия набор от скъпоценни камъни на върха, имате на върха на пръстите си арсенал, който реализира някои от най-ярките идеи в компютърното програмиране. Без суетене.
Свързани: Съкращаване на клеймото за време: Приказка ActiveRecord за Ruby on Rails
