Conference for DevOps, Software Architects and Engineers. Regular price ends 27/09!
×Закрыть

Ruby для начинающих: чем интересен этот язык и как его эффективно изучать

Меня зовут Иван Бондаренко, я Senior Software Engineer и Ruby Technical Lead в CHI Software. Опыт разработки — 6 лет, из них последние 5 — я работаю с Ruby. До этого я программировал 1 год на PHP. Имея за плечами опыт преподавания (я вел курсы по Ruby в Spalah), я решил максимально доступно рассказать об этом языке программирования, поделиться опытом с начинающими специалистами и, возможно, заинтересовать кого-то из них Ruby.

Это первая из статей, в которых я расскажу об особенностях Ruby и Ruby on Rails и поделюсь советами о том, с чего начать в изучении Ruby, где находить ответы на вопросы, как получить нужный опыт и чем вы сможете выгодно отличаться от других кандидатов. Буду рад, если мои советы помогут кому-то определиться со специализацией и выбрать Ruby для изучения и работы.

Основные особенности и отличия Ruby

Часто слышу вопрос: стоит ли учить Ruby? Как правило, вопрос основан на сомнениях: насколько легко найти работу с данной специализацией, будут ли интересные проекты и так далее и тому подобное. Ruby — современный, постоянно развивающийся язык программирования, областей применения ему — масса. Наверняка вы слышали про Chef, Vagrant, Homebrew, но чаще всего все мы слышим о Rails. Вот пост с комментарием самого автора фреймворка о том, почему стоит учить Rails.

Конечно, каждый сам для себя решает, какой инструмент ему использовать. И нет смысла бесконечно долго спорить о том, почему одна технология лучше другой. Я выбрал Ruby, потому что это невероятно выразительный и гибкий язык, который позволяет одну и ту же задачу решить многими способами.

Ruby — интерпретируемый, полностью объектно-ориентированный язык программирования с четкой динамической типизацией. Он сочетает в себе Perl-подобный синтаксис с объектно-ориентированным подходом. Также некоторые черты заимствованы из языков программирования Python, Lisp, Dylan и CLU. Кроссплатформенная реализация интерпретатора языка Ruby распространяется на условиях открытого программного обеспечения. Код, написанный на Ruby, может быть понятен даже человеку, который не разбирается в программировании. На RoR были созданы такие проекты, как Redmine, Twitter, Shopify, Basecamp, GitHub, Kickstarter, Airbnb и другие.

С ростом Node.js популярность Ruby on Rails несколько уменьшилась, но технологические стартапы часто используют RoR благодаря простоте прототипирования. Ruby — 11-й самый популярный язык в индексе TIOBE.

Преимущества Ruby

  • Многочисленное и доброжелательное комьюнити.
  • Довольно высокий порог входа, что означает, что Ruby-разработчик с большой вероятностью имеет опыт работы как минимум с еще одним языком программирования.
  • Вы используете только те библиотеки и модули, которые необходимы.
  • Существует большое количество полезных библиотек, которые уже готовы к использованию (Ruby Gems).
  • В интернете есть много информации по Ruby, в структурированном и отсеянном виде.
  • В контексте обсуждения Ruby нельзя не упомянуть популярнейший фреймворк Ruby on Rails.

А теперь поговорим о некоторых преимуществах Ruby более подробно.

Скорость разработки

Одним из плюсов Ruby и фреймворка RoR считается скорость разработки. Личный опыт и опыт коллег показывает, что решение задач на Rails происходит в полтора раза быстрее по сравнению с другими фреймворками подобного плана. Ruby очень прост как инструмент, а также существует огромное количество готовых решений для различного рода задач.

Штатные средства кеширования данных

При разработке масштабного проекта одним из самых важных моментов является кеширование. Ruby on Rails в основной комплектации имеет штатные средства кеширования данных. То есть у вас сразу будут в наличии инструменты для кеширования данных на проекте, и вы можете легко кешировать отдельные блоки кода или даже целые страницы.

Вначале тесты, потом код

Часто в процессе разработки крупных проектов возникает вопрос о тестировании, и не редкость, когда нет дополнительных средств на отдельную команду тестировщиков. В Rails есть решение и этой проблемы. Если сравнивать RoR с другими фреймворками в контексте тестирования приложения, то вы найдете массу готовых решений для любого вида тестов, будь то интеграционные или юнит. Все эти библиотеки работают «из коробки». В идеале в проекте на Ruby on Rails код не пишется до тех пор, пока под него не написаны тесты. RoR идеология предполагает изначальное использование методов BDD (Behavior Driven Development) или TDD (Test Driven Development).

Общепринятые стандарты процесса разработки у Ruby-разработчиков

Говоря о преимуществах Ruby, я не могу снова не упомянуть сообщество рубистов. Оно постоянно растет, развивается и всегда готово прийти на помощь. Всегда есть кто-то, кто подскажет, как лучше решить проблему, поделится опытом в каком-либо вопросе.

Также очень важный момент — в Ruby-сообществе уже много лет есть стандарты процесса разработки, некие правила/соглашения сообщества, по которым ведется разработка, что очень сильно упрощает работу. За счет этих стандартов каждый проект очень структурируется, соответственно, новый разработчик в команде быстро войдет в курс дела и уже с первых дней работы сможет быть полезен. И даже больше: если проект начинала одна команда, а заканчивает другая — это тоже совсем не проблема. Поскольку разработка ведется по уже упомянутым правилам и соглашениям сообщества, новая команда быстро и без трудностей вникнет в проект и успешно его закончит без особых потерь времени.

Также в Ruby on rails есть большое количество самых разных готовых решений в открытом доступе. Большинство решений уже были реализованы кем-то до вас, а также протестированы сообществом, что уменьшает необходимость разработки с нуля. Это могут быть системы аутентификации, авторизации, комментирования, системы платежей, почтовые рассылки и так далее.

Готовые решения для многоязычности проекта

Rails в базовой комплектации имеет очень мощные средства для локализации проекта. Есть возможность как предусмотреть поддержку нескольких языков изначально, так и осуществить её позже. В проекте присутствуют специальные файлы для переводов терминов, инструменты для отображения шаблонов на разных языках и многое другое.

Высокий уровень защиты данных

Сейчас нередко в сети публикуются статьи о взломах различных ресурсов. Разработчики фреймворка Ruby on Rails очень серьезно отнеслись к проблеме защиты данных. В RoR изначально присутствует шифрование паролей, данных кредитных карт и других личных данных пользователя, также исключены SQL инъекции и XSS атаки. Все входные параметры экранируются по умолчанию.

Изучение Ruby

А теперь поговорим, как именно можно освоить Ruby.

Теория

Начать следует, конечно же, с литературы. Я рекомендую эти источники:

  • Ruby за 20 минут — хороший ресурс для совсем начинающих. Позволяет меньше, чем за полчаса ознакомиться с основными конструкциями языка и начать писать свои небольшие программы.
  • Codecademy — платформа с онлайн-курсами по множеству направлений, включая чистый Ruby и Rails. Здесь довольно интересно построен обучающий процесс, дается теоретический материал и сразу же практическое задание, чтобы его закрепить. Финальные задания платные, но и без них можно получить нужные навыки.
  • Материалы по Ruby и Rails — сборник ссылок на различные сайты и книги, посвященные изучению Ruby и Rails.
  • Отдельно могу посоветовать книгу Flanagan D., Matsumoto Y. «The Ruby Programming Language». Она считается одной из лучших, её автор — сам создатель языка Ruby.
  • Google :)

Далее я рекомендую изучить хотя бы базовые понятия SQL, потому что СУБД хоть и отличаются между собой, но зачастую используют один и тот же язык.

Вот парочка ресурсов, с которых можно начать:

  • w3schools.com/sql — здесь можно почитать, попробовать и проверить свои знания по SQL.
  • quizful.net/test — тут можно найти вопросы, которые часто задают на собеседованиях.

Английский

Я считаю, что нет смысла останавливаться подробно на этом моменте, так как это — тема отдельной статьи. Английский очень важен, и это общеизвестный факт. Хотелось бы только упомянуть вкратце два самых важных момента.

Во-первых, английский — это основной язык международного комьюнити, соответственно, большая часть полезной литературы тоже будет на английском, многие новости, доклады и важные статьи тоже будут появляться сначала на английском. Если вы хотите узнать ответ на какой-либо вопрос — очень большая вероятность, что в первую очередь его получится найти именно на английском.

Во-вторых, чем лучше ваши знания английского, тем больше шансов найти работу. Большинство клиентов зарубежные, соответственно, знание английского важно для продуктивного общения, четкого понимания ТЗ и хорошего контакта с клиентом.

Практика

После изучения нескольких ресурсов стоит перейти к более важной части, а именно к практике. Примеров заданий с интернет-магазином или простым блогом в сети масса (вот один из них), особенно если говорить о Rails. В ходе выполнения задач, уже немного приближенным к реальным, вы точно столкнетесь с какими-то проблемами и тогда перейдете к тренировке одного из самых главных качеств — это умение гуглить. К сожалению, мне не удалось найти какой-то туториал или курсы, посвященные этому навыку, но он определенно играет очень важную в роль в повседневной работе.

Курсы

После прочтения теории и написания нескольких «пет-проектов» можно, конечно, пробовать идти по собеседованиям, но часто бывает, что этих знаний недостаточно. Это связано с большим наплывом кандидатов, и, учитывая конкуренцию, каждый старается выделиться и как можно лучше подготовиться.

Еще один важный пункт в обучении, который может стать перевесом в вашу сторону при поиске работы, — это курсы по программированию. Если, конечно, у вас нет ментора, который готов тратить определенное количество времени на то, чтобы придумывать задания и делать по ним ревью.

Сразу скажу, что я ни в коем случае не рекомендую идти на курсы, не имея уже какого-то багажа знаний. Я рассматриваю курсы как отличный способ закрепить знания, полученные в процессе самообучения. И сейчас не пытаюсь рекламировать какую-то конкретную школу, а объясню, какую именно пользу можно из этого извлечь:

С высокой долей вероятности там вы узнаете то, чего не знали раньше. На курсах довольно большой объем материала, который подается в структурированной форме, что позволяет лучше усваивать материал.

На период курса у вас будет ментор, который будет делать ревью решения ваших задач и указывать на слабые места и ошибки.

Обратная связь. На уроке вы можете задать интересующий вопрос преподавателю или однокурсникам или просто поделиться опытом. Конечно, то же самое можно сделать и на конференции или митапе, но в отличие от посещения конференций, на курсах у вас будет возможность делать это чаще (обычно курсы проводятся 2-3 раза в неделю).

Мотивация. Это в первую очередь для тех, кому нужна помощь с самодисциплиной. Порой довольно трудно заставить себя что-то делать, какие бы перспективы не маячили на горизонте. При посещении курсов у вас будет четкий график, которому нужно следовать, и задания, которые нужно выполнять, иначе вас исключат. Финансовая мотивация также играет здесь роль, в случае платных курсов. Ведь когда отдаешь свои кровные, то уже совсем по-другому относишься к делу, и мысли просто прогулять возникают намного реже.

Еще одно преимущество — сертификат. Понятное дело, что в итоге вас будут оценивать по знаниям, а не по наличию бумажек в резюме. Но тем не менее это будет плюсом, особенно, если будет кандидат с похожим уровнем знаний, но без их документального подтверждения.

Плюс один проект на GitHub в вашу копилку. Если вы начинающий разработчик, то вероятнее всего проект, написанный на курсах, будет интереснее с точки зрения технологий, чем те, которые были написаны ранее.

И самое главное — трудоустройство. Говоря о курсах, я не имею ввиду только те, за которые нужно платить деньги. Часто компании сами проводят набор на обучение, чтобы потом лучших взять к себе на работу. Это могут быть внутренние курсы или стажировка/интернатура. Такой вариант — наилучший, так как вам не нужно ни за что платить, вы получаете опыт и все выше перечисленные плюсы и вдобавок — реальную перспективу трудоустройства. Попасть на них сложнее, но перспективы значимее.

Итого

Ruby — это язык, который позволяет работать без большого количества неудобств и церемоний, которые приходят со строго типизированными языками. С Ruby легко начать работать, особенно если у вас уже есть опыт разработки на других языках программирования, и вы сможете быстро создавать прототипы с Ruby on Rails. В Японии, откуда он появился, Ruby использовался для создания игр. Ruby лаконичен и читается как английский, что делает код понятным для новичков.

Что касается изучения Ruby, хочу еще раз повторить: нужно начать с малого. Прочитайте несколько книг, сделайте самостоятельно несколько заданий, а затем, если чувствуете необходимость получить больше знаний и опыта или дополнительную мотивацию — можно идти на курсы, уже имея определенный багаж знаний, полученных самостоятельно.

В идеале это курсы от какой-либо компании, которая по окончании сделает вам оффер, если хорошо себя проявите. Альтернативный вариант — платные курсы, которые помогут закрепить полученные знания, добавить в резюме еще один проект и набраться опыта, что наиболее важно на старте. Но не стоит ожидать, что по окончании платных курсов вы с легкостью пройдете собеседование, показав сертификат. Оценивать в любом случае будут знания.

В то же время, имея достаточно мотивации, терпения, способностей и опыта с другими языками программирования, вы вполне можете освоить Ruby самостоятельно, т. к. в интернете очень много полезной и хорошо структурированной информации. Также благодаря открытому и многочисленному Ruby-комьюнити можно с легкостью найти онлайн ответы на многие возможные вопросы, которые с большой долей вероятности кто-то уже задавал до вас.

Удачи в изучении! А в следующей статье мы поговорим о коде.


Подписывайтесь на наш Telegram-канал для джуниоров, чтобы не пропустить интересные вакансии, стажировки, курсы, статьи.

LinkedIn

73 комментария

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Кому интересно, есть на русском статейка про ruby + RoR API и реакт: Ruby + Rails API + ReactJS
Что касается того, что рельсы убивают знание самого языка, то можно в самих рельсах использовать конструкции нативного руби, а не рельсов. Тогда будет соблюден баланс. По поводу сложности языка, то это больше относится к личным впечатлениям, при переходе с другого языка программирования. Например, для тех, кто с пыхи перешел, то язык кажется из ряда вон выходящим и нелогичным. А те, кто начинают его учить, как первый, то таких «мучений перехода» не испытывают.

Из статьи не очевидно: Ruby палочкой тыкали? шевелится?

Я бы перед тем как «практиковаться» с рельсой рекомендовал каждый день писать небольшие решения на руби (на таких сервисах, как leetcode, codewars, etc.). Чтобы не стать очередным тыжпрограммистом фреймворка, который не знает стандартных библиотек языка :D

...с четкой динамической типизацией

наверное все-таки строгой, а не четкой? :)

ч0ткой, пацанской типизацией

тогда какое отношение это имеет к Ruby?)))

Довольно высокий порог входа ...

чем что? И не добавляйте это в преимущество.

А теперь поговорим, как именно можно освоить Ruby.

Как можно дольше не трогать рельсы? :)

К у Ruby обстоят дела со IDE для разработки, возможностью дебага, CI и т.п?

Я являюсь разработчиком на .NET Framework уже много лет и прочитав эту статью пока нахожусь в недоумении.
После всех плюшек от Microsoft, Ruby с его командной строкой воспринимается как возврат в каменный век.

RubyMine от JetBrains же, визуальный дебаг, покрытие все там есть.

Только им пользуются единицы. Все сидят в атоме/vs code/sublime/vim и никаких проблем.

Только им пользуются единицы.

Это Ваше видение.
У меня к примеру — другая картина, довольно много знакомых Ruby’ов пользуются им и очень успешно

RubyMine роскошный IDE, но дебажить и работать с git-ом приятней и быстрей в командой строке, а не в нем.

После всех плюшек от Microsoft,

Вы никогда не разбирались, как работают эти самые плюшки ?
Что у них «под капотом» ? Уж не то ли, что Вы назвали «каменный век» ?

Ruby с его командной строкой воспринимается как возврат в каменный век.

Есть база.
Хотите плюшки — их вагон, и очень качественных, к примеру — RubyMine от JetBrains

Разрабатывая на Ruby большинство программистов используют ОС Linux, поэтому проблем с командной строкой не испытывают (мое субъективное мнение). IDE — RubyMine как уже сказали, либо Vim/Atom/Sublime Text + набор необходимых плагинов. Возможность дебага с «командной строкой» осуществляется библиотеками, одна из них Pry ( github.com/pry/pry github.com/rweng/pry-rails github.com/nixme/pry-nav ), при использовании RubyMine и запуска сервера с его помощью дает возможность использовать брейк поинты также как и в других IDE от JetBrains. Многие CI сервисы поддерживают Ruby — Circle CI ( circleci.com ), Gitlab CI ( about.gitlab.com/features/gitlab-ci-cd ), Heroku CI ( devcenter.heroku.com/articles/heroku-ci ).

при использовании RubyMine и запуска сервера с его помощью дает возможность использовать брейк поинты также как и в других IDE от JetBrains

Как по мне из pry дебаг в 10 раз быстрее, чем мышкой шото там нажимать в IDE))

Пользоваться терминалом каменный век? Что за бред.

Мне кажется, для разработки и отладки приложений любая IDE дает выигрыш в удобстве и производительности по сравнению с разработкой в окне терминала

с разработкой в окне терминала

Это скорее означает, что у .NET неудобные консольные инструменты. Или то, что вы лично не умеете/не любите ими пользоваться. Виндузятники, хехе.

А как вы дебажитесь из коммандной строки? Принты? Я как-то сразу начала с IDE, поэтому опыт ограничен. Было бы интересно почитать на эту тему.

Не, у Ruby есть библиотека называется pry. Она позволяет поставить что-то вроде «брейкпоинта» в коде, после чего в терминале, где запущено приложение, откроется консоль на месте этого брейкпоинта и можно там ковыряться) принтами в Ruby никто не дебажит)

Понятно, спасибо :) В python такого вроде нету

В жс тоже есть, но console.log тупо привычнее ) Только если уж прям совсем ничего непонятно — тогда брекпоинты ставлю

меня всегда поражало, как люди выбирают очевидно менее удобный инструмент в силу каких-то личных причин, морочатся с ним энное количество времени, а потом считают себя высшей кастой))). Можно конечно и микроскопом гвозди забивать, да только заведомо лучше иметь выбор консоль/нормальный гуй+шорткаты, чем не иметь этого выбора.

очевидно менее удобный инструмент

Если в .NET очевидно менее удобная консоль, чем гуй — это еще не значит, что у других так. Не нужно всех мерять по себе. У нас есть выбор, у нас есть IDE с кнопками и шорткатами, но почему-то многие выбирают таки редактор и консоль. + видела борцунов за IDE, которые даже не в курсе, что современные редакторы, внезапно, тоже имеют шорткаты, навигацию и вообще мало напоминают notepad.

звучит примерно как: «Если у вас менее удобные квадратные колеса, чем круглые, это еще не значит, что у других так. Современные квадратные колеса имеют вместо 4 граней до 4000 и на них можно прекрасно ездить». Смысл в том, что круг возможностей полноценной IDE шире, чем терминальчика. И то, что какие-то опции сделаны по-дебильному в некоторых IDE, еще не значит, что терминал лучше.

«Редактор и консоль» over «IDE» объясняется элементарно привычкой и плохо сделанными опциями отдельно взятой IDE.

Вы просто не знаете насколько удобна в руби консоль. Точнее в rails.

Вы правы, не знаю. Подскажите только, чем бы стал этот инструмент хуже, если бы на эту консоль натянуть IDE сверху?

Код обычно пишется в IDE, визуал дебаг тоже. А вот в консоли очень много тулов, например тесты, тестовые данные(просто в rails console — EntityName.New), миграции и т.п. Сборка тоже консольная, скаффолдинг тоже.

Ну вот в VS есть Package Manager Console и какие-то отдельные вещи, которые удобнее набрать ручками, вроде создания миграций, набираешь непосредственно в этой консоли. Просто зачем плодить сущности, если можно всё делать в одной IDE

так можно и какать в комнате, зачем плодить сущности? туалеты какие-то придумывают. ОДНА КВАРТИРА _ ОДНА КОМНАТА!1

Странная аналогия. Но если ее поддержать, то ide это скорее квартира со всем нужным. А у консольщиков туалет в одной квартире, кухня в другой, а спальня вообще в соседнем доме

А в чем проблема переключиться между окнами консоли и IDE?

Да собственно ни в чем, как и не проблема поставить дополнительные библиотеки дающие функционал IDE. Например библиотека для дебага, которую упоминает Елена. Все это по отдельности вообще не проблема. Просто в сумме генерирует геморрой.

Я просто не совсем понимаю зачем создавать себе мелкие или крупные проблемы, героически их решать, а потом с пренебрежением смотреть на тех, кто решил себе эти проблемы не создавать)

Просто в сумме генерирует геморрой.

А в IDE геморроя нет? По-моему, настроить IDE с нуля больший геморрой, чем натаскать нужных библиотек.

Я просто не совсем понимаю зачем создавать себе мелкие или крупные проблемы, героически их решать, а потом с пренебрежением смотреть на тех, кто решил себе эти проблемы не создавать)

Это у вас что-то личное. Вся ветка, вообще, началась с того, что консоли — это каменный век, и я тут не видел фраз о том, что IDE не нужно.

А в IDE геморроя нет? По-моему, настроить IDE с нуля больший геморрой, чем натаскать нужных библиотек.

Смотря о какой IDE мы говорим. Студию установил, открыл, создал проект, работаешь. Огромная куча функционала сразу доступна из коробки.

Это у вас что-то личное. Вся ветка, вообще, началась с того, что консоли — это каменный век, и я тут не видел фраз о том, что IDE не нужно.

Не совсем. Вот цитата от Елены, которая меня удивила

У нас есть выбор, у нас есть IDE с кнопками и шорткатами, но почему-то многие выбирают таки редактор и консоль

Лично я не считаю консоль каменным веком. Хороший программист напишет что надо и в блокноте. Да и есть вещи, которые удобнее делать текстовыми командами. Но утверждение, что IDE не нужно тоже мягко говоря странное. Выбор между IDE со встроенной консолью и консолью+IDE/редактор в соседнем окне мне кажется очевидным. Плюс забавно видеть, когда апологеты консоли+редактора выдают фразы о найденной библиотеке, которая просто дает функционал IDE, как вышеупомянутая pry. Возникает вопрос, почему сразу не взять IDE, а пытаться скруглить квадратные колеса. Хотя возможно в мире Ruby on Rails нет нормальной IDE уровня студии. Не специалист, утверждать не буду.

Студию установил, открыл, создал проект, работаешь.

Так в консоли одним скриптом установил все нужные библиотеки, создал проект и работаешь. Откуда геморрой?

Вот цитата от Елены, которая меня удивила

Это нужно обладать огромной фантазией, чтобы там увидеть «IDE не нужно».
У вас явные противоречия:

есть вещи, которые удобнее делать текстовыми командами.
Возникает вопрос, почему сразу не взять IDE
Так в консоли одним скриптом установил все нужные библиотеки, создал проект и работаешь. Откуда геморрой?

А кто написал и отладил этот скрипт?

Это нужно обладать огромной фантазией, чтобы там увидеть «IDE не нужно».:

«Почему-то многие выбирают консоль+редактор» — то есть IDE не нужно. ИМХО элементарный логический код

У вас явные противоречия:

В VS есть Package Manager Console, соответственно противоречия нет — в одной IDE сразу все нужное.

А кто написал и отладил этот скрипт?

Если для вас написать скрипт — геморрой, то у меня для вас плохие новости относительно выбранной вами работы.

«Почему-то многие выбирают консоль+редактор»

многие != все

В VS есть Package Manager Console

Устанавливаем IDE, чтобы установить пакет, чтобы из IDE работать в консоли. Зачем? Потому что так удобней, чем просто запустить консоль!

в одной IDE сразу все нужное.

Кому нужное? А вы не задумывались, что есть люди, кому это не нужно и то, как реализованы определенные функции в IDE, для кого-то неудобно? Такое ощущение, что вы проецируете собственное ощущение превосходства над теми, кому консоль+редактор удобнее, на всех остальных.

Если для вас написать скрипт — геморрой, то у меня для вас плохие новости относительно выбранной вами работы.

Как я и писал — не проблема, в принципе все эти неудобства по отдельности не проблема, но в сумме они забирают время. Непонятно зачем, если можно взять IDE, где это уже все готово.

многие != все

я и не говорил, что все

Устанавливаем IDE, чтобы установить пакет, чтобы из IDE работать в консоли. Зачем? Потому что так удобней, чем просто запустить консоль!

Нет, в IDE уже есть эта консоль, ничего не нужно устанавливать. Не нужно ничего дополнительно запускать, прописывать и так далее. Я не говорю, что это сложно, я говорю, что это забирает время.

Кому нужное? А вы не задумывались, что есть люди, кому это не нужно и то, как реализованы определенные функции в IDE, для кого-то неудобно? Такое ощущение, что вы проецируете собственное ощущение превосходства над теми, кому консоль+редактор удобнее, на всех остальных.

так ну это вопрос подбора нормальной IDE. Абстрактная IDE лучше абстрактной консоли+редактора по определению.

Условно говоря, в вашем основном инструменте для программирования x% функций реализовано хорошо, (100-x)% плохо. Таким образом нужны дополнительные библиотеки/ухищрения/переконфигурирования для (100-x)% функций.
В связке консоль+редактор X стремится к нулю. Что говорить, если люди для элементарного дебага используют доп. библиотеку.

Но если в вашей среде нет хорошей IDE, то да, возможно в вашей конкретной области выбор консоль+редактор оптимальнее. Но это до тех пор, пока не появится хорошая IDE.

В связке консоль+редактор X стремится к нулю.

facepalm.jpeg

Но это до тех пор, пока не появится хорошая IDE.

Ну, с вами все понятно: есть только ваша точка зрения и неправильная, распространяемая надменными снобами, не видевших нормальную IDE как Студия!

facepalm.jpeg

а что в консоли доступно просто из коробки? Без написания «безпроблемных скриптов», «подтягивания библиотек» и т.д.

Ну, с вами все понятно: есть только ваша точка зрения и неправильная, распространяемая надменными снобами, не видевших нормальную IDE как Студия!

омг, ну я так и не увидел толкового аргумента, чем IDE хуже связки консоль+редактор. С натяжкой можно сюда отнести аргумент, что IDE тяжеловеснее. Да, но учитывая мощности современных компьютеров, это уже нерелевантно. Еще был аргумент, что дескать в связке консоль+редактор можно настроить все под себя. Но это же можно сделать и в IDE. Просветите меня, темного

а что в консоли доступно просто из коробки?

В консоле нет «из коробки». Устанавливается только то, что нужно. По вашему установка IDE занимает меньше времени, чем установка нужных библиотек?

Но это же можно сделать и в IDE.

У вас какие-то дикие противоречия. Ставите в плюс IDE то, что она «из коробки» все может и не нужно ничего настраивать, и тут же пишете, что можно настроить все. Так если нужно все настраивать, то получается тот же «геморрой» и «потеря драгоценного времени». В чем тогда преимущества?

Еще был аргумент, что дескать в связке консоль+редактор можно настроить все под себя.

Нет, аргумент в том, что можно подобрать удобные конкретному пользователю инструменты, а не ставить костыли, если что-то неудобно.

В консоле нет «из коробки». Устанавливается только то, что нужно. По вашему установка IDE занимает меньше времени, чем установка нужных библиотек?

Установка IDE происходит один раз и занимает до получаса. Во время которого можно заниматься чем угодно. Подключение нужных библиотек/написание скриптов требует личного присутствия и вложения времени.

У вас какие-то дикие противоречия. Ставите в плюс IDE то, что она «из коробки» все может и не нужно ничего настраивать, и тут же пишете, что можно настроить все. Так если нужно все настраивать, то получается тот же «геморрой» и «потеря драгоценного времени». В чем тогда преимущества?

омг. Вы правда не понимаете или притворяетесь? Из коробки получается адекватная среда, которая умеет многое. Если ваши вкусы специфичны, то можете настроить под себя. Лично я в студии после установки меняю две галочки и всё. Вложение личного времени — меньше минуты — запустить установку, выбрать нужные компоненты (совместимость которых уже проверена до меня), открыть студию поменять две галочки. Сколько у вас АКТИВНОГО времени займет сделать рабочую среду из консоли, не имея еще скриптов/надстроек/библиотек? Сколько раз вам приходилось встречаться с несовместимостью отдельных библиотек?

Нет, аргумент в том, что можно подобрать удобные конкретному пользователю инструменты, а не ставить костыли, если что-то неудобно.

ха, забавно. То есть в IDE это костыли, а в консоли «удобные конкретному пользователю инструменты». Интересное двоемыслие.

Во время которого можно заниматься чем угодно.

Я не знаю, может сейчас VS умеет читать мысли, но раньше приходилось указывать путь для установки, клацать кнопочку «далее», потом в середине установки мог внезапно вылезти какой-то вопрос по установкам/обновлениям библиотек и т.д.

Лично я в студии после установки меняю две галочки и всё.

Вот и возвращаемся к

есть только ваша точка зрения и неправильная, распространяемая надменными снобами, не видевших нормальную IDE как Студия!
Сколько у вас АКТИВНОГО времени займет сделать рабочую среду из консоли, не имея еще скриптов/надстроек/библиотек?

Те среды, с которыми я работал — минут 10-15. Потом, конечно, если что-то нужно, то подтягивается что-то еще. Но это же делается один раз во время знакомства со средой. Потом уже есть скрипт или по памяти подтягивается то, что нужно. И времени уходит еще меньше.

То есть в IDE это костыли

Костыли, потому что дублируются уже имеющиеся функции, например в большинстве IDE уже есть инструменты по работе с VCS, но по вашим же утверждениям, большинство сидит в консоле. Я не знаю как по другому это назвать как не костылем.

Я не знаю, может сейчас VS умеет читать мысли, но раньше приходилось указывать путь для установки, клацать кнопочку «далее», потом в середине установки мог внезапно вылезти какой-то вопрос по установкам/обновлениям библиотек и т.д.

далее-указали путь-далее-далее-указали компоненты-далее. Вопросы, как правило не возникают.

Те среды, с которыми я работал — минут 10-15. Потом, конечно, если что-то нужно, то подтягивается что-то еще. Но это же делается один раз во время знакомства со средой. Потом уже есть скрипт или по памяти подтягивается то, что нужно. И времени уходит еще меньше.

Окей, вот уже на простом примере 1 минута против 15. Не говоря уже о возможных опечатках, отладке скрипта и так далее. В IDE ты думаешь о программировании, а не о том, какую библиотеку выбрать для дебага))).

Костыли, потому что дублируются уже имеющиеся функции, например в большинстве IDE уже есть инструменты по работе с VCS, но по вашим же утверждениям, большинство сидит в консоле. Я не знаю как по другому это назвать как не костылем.

щито? Я сказал, что есть Package Manager Console из которой можно, например, подтянуть пакеты. Я не утверждал, что большинство сидит в консоли. Там выполняется ограниченный перечень задач — вроде добавления миграции.

В IDE ты думаешь о программировании, а не о том, какую библиотеку выбрать для дебага))).

Да-да, IDE волшебный образом загружает в мозг все знания о ее использовании, не нужно разбираться в настройках, читать документацию, запоминать hotkeys. Это ж только для работы в консоле нужно все учить и запоминать и постоянно выбирать.

Мне привычнее например с гитом работать или всяким npm в консоли, хотя пишу в IDE и интеграция там есть почти со всем (или вообще со всем). Привык так. Но вот если нужно резолвить конфликт при мердже, то средства IDE мне удобнее и пользуюсь ними.

с аргументом «привычнее» я согласен. Это вообще очень часто решает. Но вот когда начинают натягивать сову на глобус в попытках доказать, что IDE не нужна, то звучит забавно

Не менее забавно, чем когда доказывают, что консоль — каменный век.

Да, всё субъективно. Я первое время на линуксе страдал без гуёв для гита (а хороших гуёв пару лет назад не было, а под винду был удобный SourceTree). А потом я так привык, что стало наоборот — лучше консоль. В частности, консольный клиент шустрее, а основные команды запоминаются быстро. Но для некоторых задач удобнее интеграция с IDE — там удобно сравнивать две версии файла side-by-side и мерджить при конфликтах.

Ну для меня лично, основной аргумент за CLI:
— я хочу понимать что происходит. Я не хочу терять понимание процесса. Я хочу понимать какие компоненты, как они работают, как их можно использовать, комбинировать ... такое понимание дает именно CLI.
В широком смысле — это вопрос, насколько
— я обожаю CLI как инструмент

это вопрос, насколько

я понимаю процесс

Больше всех доказывают те, у кого IDE нет

Или те, кто сбежал от Visual Studio.

Есть нюанс. Если человек хочет работать в виме или пусть даже в Notepade, то и флаг ему в руки, пусть хоть в gdb руками команды вводит, а когда хочется функционала IDE, а его нет, то неприятненько.

Поэтому такая реакция сохраняется, пока не увидят нормальный IDE.

список нормальных в студию)

любая IDE дает выигрыш в удобстве

Очень от IDE зависит. Чаще всего IDE тупо не умеет использовать половину функций, которые дает консоль. Вот ни в одной IDE не видел хорошую интеграцию VCS, которая заменит командную строку.

А я видел: magit.vc

Не буду агитировать за его использование, но конкретно magit — лучший git клиент из всех, что пользовал, очень рекомендую, и дока на оф. сайте хорошая.

Практически любая IDE умеет встроенный терминал, но не наоборот ;)

Чем встроенный терминал отличается от обычного?

Это же не холивар IDE vs Terminal. Речь идёт о

любая IDE дает выигрыш в удобстве

А удобство в чем? Запустить тот же терминал в IDE?

как минимум привычные команды гита всегда с вами, ну и интерактивный терминал питона/скалы/etc

Это же не холивар IDE vs Terminal.

Вот именно. Лучше иметь и то, и это

Брєд із бронзового віку wysiwyg-програмування

Хорошая статья, спасибо.

Хоть в статье и сказано про высокий порог входа и то, что язык обычно изучается не первым, считаю Ruby отличным языком для начинающих веб-разработчиков и что этот порог входа следует преодолеть. Все благодаря качественной экосистеме Рельс, крутому комьюнити и шикарным учебным материалам и книгам, аналогов которых по качеству я не видел ни в PHP, ни в Питоне, ни в JS’е.

По моему мнению Рельсы прививают качественное и правильное понимание MVC архитектуры, ORM, разработку через тесты, учат сразу красивому, чистому и выразительному коду как на бэке, так и на фронте (CoffeeScript навсегда останется в моем сердце).

Сейчас работая с ларавелем и пхп я не удивляюсь такому количеству говнокода в легаси проектах, ибо начинать изучать веб с пхп или еще хуже — с JS — это провал и за легкостью входа и alert(’Helloworld’); теряется изучение и понимание фундаментальных основ программирования в целом.

Кстати, а почему перешел с Рельсов на Ларавел? Рельсы то помощнее будут

Не от меня решение зависило. Конечно, я бы с удовольствием остался бы на рельсах.

Спасибо, полезно!

Подписаться на комментарии