• Есть ли выгода от переезда в столицу из миллионика?

    @developer007
    А че все про зарплаты да про зарплаты?
    я ахерел когда увидел настоящие ливневки РАБОТАЮЩИЕ КАРЛ, а не закопанные в асфальт.
    Нет дерьма на дорогах т.к их периодически моют тракторами/камазами.

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

    Можно на самокате поехать на работу и никто не назовет инфатильным пидаром.

    В провинции такого нет.
    Так что стоит переехать ради цивилизации. Хату можно снять рядом с работой (на той же ветке).

    ИМХО: думаю переезд в МСК для молодых движовых парней. Если есть семья, квартира и зарплата выше рынка , то смысла нет ехать
    Ответ написан
    11 комментариев
  • Есть ли выгода от переезда в столицу из миллионика?

    php666
    @php666
    PHP-макака
    Я никуда не переезжал, живу в Подмосковье всю жизнь.
    Что вижу.

    Вся работа по IT сосредоточена прям в ЦЕНТРЕ Москвы. Найти работу хотя бы около МКАДа почти нереально (единичные вакансии с небольшой зп), за МКАД её вообще нет. И это на PHP. Т.е. не надо думать, что Москва - это прям it-столица. И близко такого нет.

    Я живу географически в 5 км от МАКАД, ночью до Кремля мне на машине ехать минут 25 - не больше. В будние дни, бывает, я только из своего города выезжаю 2 часа. Т.е. перенаселенность Московского региона просто чудовищна, а инфраструктура осталась из 70-90 годов. Я банально порой не могу найти работу, ибо тратить по 2-2.5 часа в одну сторону (поездка в центр) - это нереально, это не выдержит ни один человек. И не важно, на авто или пешком. Но вся самая вкусная работа именно в центре.

    - Если снимешь квартиру в Подмосковье - ты взвоешь, без машины тут никак. Кто бы что не говорил и не рассказывал как увлекательно каждый день ждать электричку на бодрящем февральском морозе и тратить всё свободное время на дорогу на работу.
    - Если снимешь в Москве, около метро - то будет лучше, но выше всё сказали о твоем профите. Смысла со 100 до 140 нет никакого, всё съест аренда.

    Да и на 4,5 ничего нормального не купить из недвижимости.
    однушка в Москве стартует от 7 млн. рублей. А покупать жилье за МКАДОМ категорически не надо. Открой Яндекс-пробки (будние дни, с 7 утра) и посмотри на вечный стояк Подмосковья. Тут жизни нет уже лет 10, как только началась массовая застройка и миграция из регионов. Для убедительности можешь приехать в любой новый муравейник микрорайон и посмотреть, как люди там живут. Если ты человек нормальный, тебя должно стошнить.
    Ответ написан
    11 комментариев
  • На каком свете сейчас Ruby?

    OnYourLips
    @OnYourLips
    На hh 50 вакансий с зарплатой 190+ (грубо говоря, уровня сеньора) по рельсам в Москве.
    30 по Django
    25 по Laravel.

    Так что относительно популярен, хоть я и думал иначе (как и DevMan).
    Принцип оценки вы поняли: смотреть сайты по поиску работы.

    Еще очевидный плюс RoR - это имхо самый низкий уровень вхождения до джуна за счет отсутсвия фрагментации. В python, а тем более в php и js этот путь будет значительно дольше.
    Ответ написан
    4 комментария
  • Можете оценить в часах время выполнения тестового задания на Ruby?

    OnYourLips
    @OnYourLips
    8 часов для первого - крайне оптимистичный прогноз, если делать нормально.
    Подобное задание должно быть оплачено кандидатам вне зависимости от успешности его выполнения.
    Ответ написан
    Комментировать
  • Книги про бэкенд разработку на Go?

    AlanIkaev
    @AlanIkaev
    Developer
    Держи отличный курс
    Ответ написан
    Комментировать
  • Какие технологии нужно знать для создания мессенджера?

    Сервер пишете на Erlang, клиент на Haskell. Сторонние библиотеки не нужны, всё необходимое есть из коробки. Для новичка самое то. Литературы в интернете полно.
    Ответ написан
    1 комментарий
  • Какие технологии нужно знать для создания мессенджера?

    Sanasol
    @Sanasol Куратор тега Веб-разработка
    нельзя просто так взять и загуглить ошибку
    Самая важная технология которую нужно знать: Google Search.
    На базе этой технологии построены лучшие в мире проекты.
    Ответ написан
    6 комментариев
  • Что производительнее Go или Erlang?

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

    derek2
    @derek2
    Верстальщик
    Какой-то странный ты курс проходить начал : /
    На самом деле, я бы начинал изучение 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 или иной язык. Думаю, что на этом всё

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

    На этом всё, удачного освоения языка ;)
    Ответ написан
    1 комментарий
  • Для чего идеальна MongoDb? Примеры приложений, где монга будет лучше mysql?

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

    Wolfnsex
    @Wolfnsex
    Если не хочешь быть первым - не вставай в очередь!
    Я расскажу Вам про личный опыт, без претензий на истину в последней инстанции...

    Для чего идеальна 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" - активно развивается... Со всеми вытекающими.
    Ответ написан
    7 комментариев
  • Какие области в веб - разработке осваивать в перспективе?

    dom1n1k
    @dom1n1k
    В общем у меня уйдёт на это 2 - 2.5 месяца. Только на основы!

    Ну обосраться. Два грёбаных месяца!!!1
    До чего докатилась индустрия, что 2 месяца воспринимаются как огромный срок. И всё чаще натыкаешься на статьи, где пишут о годовалых якобы мидлах и трехлетних якобы сеньорах.
    Лично я считаю, нужно потратить от 2-3 лет, чтобы начать более-менее прилично и системно ориентироваться в теме. В течении этих лет неоднократно будут возникать моменты, когда тебе кажется, что ты уже достаточно крут - но это только кажется.
    Нормальный специалист средней руки формируется около 3 лет. Не гуру, не сенсей, не сеньор - просто крепкий линейный боец. Это много где так, не обязательно в JS. И это нормально.
    Хочешь за несколько недель - иди установщиком пластиковых окон, как раз строительный сезон начался.
    Ответ написан
    11 комментариев
  • Можно ли начать учить Ruby on Rails без знания Ruby, но со знанием другого бекенд языка?

    c3gdlk
    @c3gdlk
    Ментор в http://rubyboost.ru/
    Спокойно учится, если Ваш код будет кто-то смотреть. Я так как раз с Yii семь лет назад пересел, абсолютно не ощущал проблем с незнанием языка.

    Но, важно то, что мне всегда показывали ruby-way решение. Самый сок руби в метапрограммировании и его так просто с наскока все равно не возьмешь. А в остальном разницы не особо много, просто будет не привычно, что куча всего готового из коробки, будете по привычки костыли делать. Именно для этого и нужен наставник
    Ответ написан
    Комментировать
  • Как грамотно выстроить план обучения и развития?

    oh_shi
    @oh_shi
    1) спросите у вашего работодателя, что они хотят увидеть через год. Сравните с вакансиями на аналогичные должности;
    2) изучайте все по мере необходимости, но 'одеваться следует для той работы, которую вы хотите иметь, а не для той, которую имеете';
    3) есть смысл первые несколько лет тратить все свободное время на обучение, чтоб быстрее добраться до определенного уровня навыков и $/час;
    4) английский;
    Ответ написан
    Комментировать
  • Почему Vue.js стал популярен в связке с Ruby on Rails?

    c3gdlk
    @c3gdlk
    Ментор в http://rubyboost.ru/
    Потому что он проще чем реакт, имеет много общего с HTML и интуитивно понятнее. У нас, если нет ресурсов фронт команды на проект, разработчики выбирают вуе, потому что как показывает практика он гарантированно учится за 3 дня бекэндерами.

    P.S. Лично мне фреймворк не понравился, но я и на фронте в свое время довольно много писал и теперь React one love
    Ответ написан
    Комментировать
  • Почему разработчики Ruby не любят создавать индексы в базах данных?

    OnYourLips
    @OnYourLips
    Это шутка, вызванная крайне низким уровнем вхождения в экосистему Ruby on Rails.

    Автор книги грубо подкалывает среднестатистического неопытного RoR разработчика, перенося акцент на инструмент. Такое допустимо в дружеской беседе, но в книге выглядит грязно.
    Ответ написан
    Комментировать
  • Есть сервис для того, чтобы научиться бегло понимать английскую речь?

    Мне очень нравится duolingo.com. Он бесплатен, у него отличный дизайн и хорошая идея:
    1. Проходите ряд бесплатных курсов с интерактивными упражнениями.
    2. Участвуете в краудсорсинговом переводе текстов, улучшая свой навык языка.

    Если же говорить именно о восприятии на слух, то у меня всё сложилось следующим образом:

    а. Начал с просмотра фильмов строго на английском. Смотрим с субтитрами, ставим на паузу и переводим. Да, неприятно поначалу, но вы решите: вы учите или ищете "новые способы". Если учите, то смиритесь с напрягом на первые несколько фильмов. Уже на 5-м, скажем, увидите прогресс: останавливать надо будет заметно реже. Довольно быстро вы начнёте получать новое удовольствие от просмотра в оригинале. Мне иногда говорят: но я же не понимаю по английски, как смотреть? А я отвечаю: что за проблема, если вы не поймёте половину фраз в фильме? Вам хоть один просмотренный фильм хоть что-то дал, при полном понимании сказанного в нём? То-то.

    б. Дальше пошло чтение, начиная с простого и увеличивая сложность. На андроиде удобно читать, есть интеграция со словарём. Я использую FBReader + GoldenDict.

    в. Вообще, везде, где только можно, окунайтесь в языковой контекст. Интерфейс всего софта - только англ., если друзья знают язык - переписывайтесь с ними на нём, посещайте встречи, где говорят на английском, ищите носителей на couchsurfing.org (организуют встречи, на которых путешественники знакомятся с местными).

    г. Аудиокниги и подкасты - это шикарно. Потому, что вы можете учить язык каждый день часами: в дороге, во время пробежки и так далее. Аудиокниги качайте на торрентах. Ну, можете взять одну бесплатно в Audible. Клёвые подкасты: 99% Invisible, Freakonomics, NPR Planet Money, NPR Ted Radio Hour, The Moth. Тысячи их.

    Вообще, советую не париться и слушать речь. Вы будете волноваться оттого, что ничего не понимаете. Не волнуйтесь и продолжайте слушать. Понимание придёт со временем, сами удивитесь. Собственно, дети именно так и учат, что даже потом становятся теми самыми "носителями", а нам, взрослым, проще, есть жизненный опыт.

    P.S. Я свободно говорю и пишу на англйиском, в ряде контекстов мне вообще всё равно, на каком языке говорить. Таким же способом учу немецкий, на котором могу изъясняться через пень-колоду. Английский начинал с типичного для наших широт "intermediate" (что-то учили в институте). Немецкий начал с нуля.
    Ответ написан
    3 комментария
  • Что изучать: Ruby или Node.js?

    mr_ffloyd
    @mr_ffloyd
    Я рубист и c нодой работал мало. Гораздо больше с клиентским js'ом. Мое мнение, что лучше ruby/RoR по следующим причинам:

    1) Язык. Дизайн ruby превосходит js наголову, объективно. Просто зайдите на wtfjs.com и полистайте.

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

    2.5) Я не знаю ни одного человека успешно изучавшего haskell, который не смеялся бы над js. Может такие есть, но это редкие звери) Я это к тому, что полезнее уделять больше времени языкам, которые содержат в себе мощные и слаженные между собой идеи, вникать в эти идеи, развивать мозги. Посмотрите на Scala: мощнейший и довольно сложный язык, но изучая его просто для себя я заметил, что стал лучше писать на ruby и c/c++. Js мне такого блага не давал.

    3) В RoR среде средний уровень качества кода выше. Это мнение я слышу часто и склоняюсь к тому, что это правда. Порог входа в js сильно ниже порога входа в ruby, RoR старше и матёрее.

    4) NPM догнал rubygems количеством, но не качеством.

    5) Для большинства сайтов вполне хватит rails-based-инфраструктуры.

    6) Насчет перспективности. Технологии стремительно развиваются, но я практически уверен, что RoR будет на пике еще лет 3-5 минимум. Что будет потом - я не знаю. Но поработав с RoR вы научитесь многому у него и у самого языка. А если хочется поработать на низком уровне с сервером - я бы рекомендовал Scala/Akka, Erlang/OTP, go, clojure еще можно. После них реши вы писать код на node.js - он будет красивее и чище нежели без подобного опыта.

    In suma: RoR будет сложнее, но полезнее для мозгов. Перспективно уметь функциональщину. Главная и огромная беда node.js - в языке. Как идея он хорош.

    А вообще - главное чтобы самому хорошо было. Попробуйте ruby как язык - может несмотря на все вышесказанное он вам банально придется не по душе)
    Ответ написан
    4 комментария
  • Как организовать хранение товаров-замен для оптимизации поиска?

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

    Ну и, само собой, индекс по этому дополнительному полю.
    Ответ написан
    Комментировать
  • Как организовать хранение товаров-замен для оптимизации поиска?

    sim3x
    @sim3x
    Но тогда таблица разрастается до огромных размеров - сотни миллионов строк (в наших условиях).
    и прекрасно. Все равно там только три инта хранится, не так ли?

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