eliastro

Если задача померяться с пацанами в ЖЖ цифрами и продемонстрировать что ты быстрее эрланга на 5-10% — то Го. Если ты хочешь более-менее фунциональный веб, то Erlang конечно. Но на Го так быстро слепить бенчмарк для веб, который нагнет Erlang не так то просто.

Какой-то странный ты курс проходить начал : /
На самом деле, я бы начинал изучение Ruby с того, как правильно он произносится. Но не суть...
Если по-серьёзному, то советую прочесть книгу "Head First. Изучаем Ruby". Там всё легко и понятно, нет никакой воды (правда, некоторые темы затрагиваются на протяжении нескольких листов, хотя их можно расписать и в один). Если тебе нужен, так называемый "путь самурая", то нужно взять что-то посерьёзней, например, Хэл Фултона с его "Путь Руби" В этой книге расписаны до невозможности все принципы ООП. Также есть книги от самого создателя языка Юкихиро Мацумото "Ruby in a Nutshell" и "The Ruby Programming Language". В ютубе существует достаточное количество мануалов и прочей фигни по Рубину. Также невозможно обойтись без документаций: API и офишл доки.
После этого можно уже приходить к вебу, вот там как раз-таки надо знать RoR и прочие фреймворки, типа Sinatra, Roda, Hanami, Grape. Стоит заметить фронтенд либы bootstrap, ну и пакет модулей Webpack. Если учить тупо RoR, то тут уже у всех на языке книга Майкла Хартла с его клоном Твиттера и множества рекламы в начале (зато присутствует неплохая практика с Git, Хероку и линуксовыми командами). И вообще, если не ошибаюсь, то любой фреймворк Ruby невозможен без системы MVC (Model View Controller). Ну, ещё тебе может ещё потребоваться ознакомиться с синтаксисом SASS или SCSS, но там ничего трудного. На равне с этим нужно будет ознакомиться с *nix-подобными системами и их неотъемлемым Терминалом, который может послужить тебе даже таблеткой от запора, в случае чего.
Да и вообще, Руби пригоден не только для веба. Для него существует и RubyMotion, являющимся неким фреймворком для разработки под iOS, а на Ведроид- ruboto, который, хоть и стоит уже на последнем издыхании, но, всё же, способен дать какие-то мизерные плоды (ага, а ещё его сайт взломали пару лет назад). На руби крипту даже написали
Смысла задумываться над другими языками, как мне кажется, нет. О том же PHP думать можно, но имхо он востребован только в связке с ведущими фреймворками... Ну если тебя не устроит, всё же, Руби, то переходи на ведущие Java, Kotlin или иной язык. Думаю, что на этом всё

Устроиться на работу без опыта практически нереально. Да еще и за бесплатно (хотя дешёвую рабочую силу никто не отменял). Только мешаться будешь (здесь личный опыт уже). Но это совсем не означает, что таких вакансий нет. Чекни их с того же "Моего круга". В универ идти необходимо, чтобы, как минимум для приличия, да и в армейку не угораздишь. Никто не возьмёт тебя на первую работу без диплома об окончании вуза. Это уже потом, когда у тебя будет достаточно опыта, то диплом уже будет не актуален.

На этом всё, удачного освоения языка ;)

Я работаю с MongoDB на протяжении уже 4х лет. Имеется ряд проектов, созданных как с использованием этой БД, так и использованием классических RDBMS.
MongoDB это не MySQL и не PostgreSQL. Большинство людей пытается сравнить оба типа баз данных, но это абсолютно глупо и неприемлемо. Это все равно что сравнивать врачей и инженеров.
MongoDB подойдет там, где нужна гибкость структуры и большие объемы данных. Например хранение истории болезни пациентов в масштабе страны. Каждая карточка может быть разного типа со множеством полей. И их могут быть триллионы. Для классических реляционных БД это выливается в весьма нетривиальную задачу горизонтального масштабирования, которая в MySQL решается через перенастройку сервера, а в PostgreSQL через специальную промежуточную таблицу. Горизонтальный рост и ввод новых узлов кластера сопряжен с большими трудностями и плохо автоматизируется для реляционных БД.
Еще классические БД очень плохо работают со смешанной нагрузкой, когда у вас запись/чтение примерно 1:1 и данных очень много. Это вызывает непрерывное перестроение индексов и их использование больше мешает. Это тот тип нагрузки, при которой InnoDB частенько повреждается без возможности восстановления или что вызывает значительный простой на реорганизацию структур данных.
Также существует очень много задач, для которых использование MongoDB исключительно неприемлемо. Если вам необходимо работать с нормализованными данными - используйте реляционные БД. Если нужна мощная аналитика - колоночные. Разумеется, каждая из этих опций имеет свою цену.
На рынке нет универсального решения. Каждое заточено под свои задачи.

Я расскажу Вам про личный опыт, без претензий на истину в последней инстанции...

Для чего идеальна MongoDb? Примеры приложений, где монга будет лучше mysql?

Для человека который привык работать с реляционными БД, смириться с логикой и вообще с подобными БД - довольно сложно. Для тех, кто работает с реляционными БД профессионально - сделать это ещё сложнее...

Если сравнивать с реляционными БД и с оглядкой на конкретно MySQL - монга идеально вписывается там, где структура данных заранее неизвестна. Тут я хотел привести пример, но не смог придумать ни одного дельного примера, после того как начал плотно работать с PostgreSQL... Давайте попробую из практики. Мы один раз применяли монгу в проекте где есть десятки и сотни тысяч товарных позиций и у каждой из них свой уникальный набор различных свойств. На основе уже имеющихся свойств, "соседних" товаров, контентщику предлагался наиболее вероятный набор параметров, которые нужно заполнить, но в любой момент он мог удалить или добавить любое поле и/или множество значений одного из них, например, "Цвет: черный, серый, фиолетовый". Всё это дело попадало под разные динамические фильтры и далее по цепочке... В то время, насколько я помню ещё не было поддержки JSONB-формата у PostgreSQL, по этому мы остановились на MongoDB. Ну и конечно же, желание "воткнуть ультра новую и модную БД в проект" сыграло свою роль...

Что в монге определённо не нравится (и это не моя "идея", об этом пишут даже в учебниках под монге) - это тотальная денормализация данных. Которая в некоторых случаях может сыграть злую шутку. Например, все комментарии "поста" обычно хранятся прямо в самой сущности поста. Это очень удобно и довольно быстро работает, но... иногда это приводит к полному коллапсу. Особенно, когда у Вас перекрестная ссылочность.

Безусловно, не редко можно встретить проекты в которых даже в реляционных БД не прописаны, например, внешние ключи и контроля целостности данных как такового нет, но обычно это происходит по следующим причинам:
1. Очень низкая квалификация администратора БД проекта
2. В попытке выжать из базы больше производительности, не найдя других методов оптимизации
3. Данных настолько много, что БД/ключи - начинают "сыпаться", не редко это связано с п.1

Так же, последние тесты показывают, что PostgreSQL почти не уступает MongoDB даже в её родной среде (на уровне данных в формате JSON). А в некоторых аспектах даже превосходит её... Подробности Вы можете увидеть на некоторых конференциях по Postgres (да, на конференциях по MongoDB, Вы вряд ли увидите, как кто-то будет рассказывать, что [их любимая] монга "хуже" некоторых других движков...). Кстати, поддержку формата JSON стандартизировали (наконец-то) на уровне SQL-стандарта (если я не ошибаюсь) и в самом ближайшем будущем, думаю стоит ожидать полноценную поддержку оного в SQL-базах, в т.ч. поддержку в бинарном виде с возможностью индексации данных (кстати, некоторые SQL-базы уже такое умеют).

Моё понимание, ответа на вопрос, "когда действительно стоит использовать MogoDB?" звучит примерно так: Исключительно в тех случаях, когда Вы понимаете, что она станет действительно хорошим решением для поставленной задачи и сейчас и в будущем. В моей практике, таких проектов можно было бы насчитать ничтожно мало, а точнее около нуля, особенно с учётом развития некоторых современных SQL-БД и вообще направления "JSON в SQL" в целом. Но, безусловно такие проекты могут быть и есть (в данном случае, не у меня). Но, тут стоит обратить внимание на крайне важный факт - когда всплывает такой проект, что бы адекватно оценить наиболее оптимальную БД под него - нужно знать как минимум пару-тройку SQL-БД, со всеми их особенностями, достоинствами и недостатками... причем не просто "знать", а хорошо знать, "изнутри". А так же знать все характерные черты монги, а так же её особенности, достоинства и т.д. То есть, если Вы задаётесь вопросом, "а хорошо ли впишется монга в проект N?" и не можете найти на него однозначного ответа, вероятнее всего, что в долгосрочной перспективе, в "проект N" она впишется плохо.

P.S. В заключение, хочу ещё раз напомнить, что "JSON в SQL" - активно развивается... Со всеми вытекающими.

1) спросите у вашего работодателя, что они хотят увидеть через год. Сравните с вакансиями на аналогичные должности;
2) изучайте все по мере необходимости, но 'одеваться следует для той работы, которую вы хотите иметь, а не для той, которую имеете';
3) есть смысл первые несколько лет тратить все свободное время на обучение, чтоб быстрее добраться до определенного уровня навыков и $/час;
4) английский;

Потому что он проще чем реакт, имеет много общего с HTML и интуитивно понятнее. У нас, если нет ресурсов фронт команды на проект, разработчики выбирают вуе, потому что как показывает практика он гарантированно учится за 3 дня бекэндерами.

P.S. Лично мне фреймворк не понравился, но я и на фронте в свое время довольно много писал и теперь React one love

Если замены двунаправлены независимо от уровня, то есть (по приведённому Вами примеру) A является заменой для E, то можно просто ввести ещё одно поле, которое будет одинаковым для всех товаров в одной группе замены. Что-то вроде связи многие-к-одному, но без дополнительной таблицы. Хотя никто не мешает ввести и дополнительную таблицу, чтобы дать имя группе замены.

Ну и, само собой, индекс по этому дополнительному полю.

В поиске довольно много ответов по этой проблеме. Ни один не подошел?
Где пишут, что рестарт надо делать, где - что это легаси омниауса.

Свиду, вроде, все правильно, но:
1. Что за ссылка localhost:8080/users/auth/vkontakte.user ? Обычно она выглядит как localhost:8080/users/auth/vkontakte
2. Для чего аттр_акссессоры у юзера?
3. Почему идентифицируете пользователя по ссылке, а не по паре провайдер+uid ? Люди любят менять никнеймы
4. Это опечатка?
resource_name, provider:provider

provider передается как параметр, а не как часть хэша. Вот скопировал из своего рабочего проекта:

link_to "Sign in with #{provider.to_s.titleize}", omniauth_authorize_path(resource_name, provider)