kystick, Вы работодателя представляете как нечто абстрактное. Примерно также, как большинство представляет государство. По факту Ваш гитхаб посмотрить одит только лишь технический спец, отвечающий за тех интервью. Точнее не посмотрит, а может посмотреть.
Если у Вас действительно хороший гитхаб, то составте карту-документ с описанием куда смотреть и что там можно увидеть. Иначе гитхаб никто смотреть не будет. Потому что тупо лень ковыряться в чужом недокументированном и неструктурированном непонятно чём.
Да, судя по всему он умеет сам организовать пул соединений. Но, вы не используете эту возможность, так как заново инициализирует инстанс. Попробуйте http = ... Вынести за все циклы и посмотреть что будет
Александр это уже когда специалист. Я например, ненвижу JS и GO, оба отвратительных языка и я бы мог по каждому книжку написать, почему они конченые. Но я довольно много пишу на каждом из них, потому что отрицать их существование и преймущества не разумно. И JS мне невзлюбился с самой первой лекции о нем в универе. Я тогда точно и слова аргументированно не мог бы о нем плохого сказать, но работать в нем бы точно не стал. Это очень важно, когда ты только начинаешь. Перед тобой тысяча вызовов, которые кажутся смешными опытным товарищам. И если нет запала, нет интереса, то преодолеть их будет сложно
И мы говорим о джунах, которым и так довольно сложно. Я честно против руби как языка для новичка, потому что он сильно высокоуровневый. Очень многое делает за тебя. Считаю что без понимания того, как он это делает, пользоватьяс им немного вредно. Я очень рад что моим первым языкком в универе был Паскаль. Простой как палка, никаких скрытых и неочевидных для новичка штук. Самое то парню, который до поступления в универ компьютер в глаза не видел.
Но если душа лежит именно к технологии X, то нужно найти работу именно в понравившейся технологии. Я первую работу в руби нашел как помошникк фрилансера, на местном форуме, а не сайте с вакансиями. Так что Ваш скрин не может быть 100% актуальным.
P.S. насчет удаленки полностью согласен. Джун на удаленке чему-то научится в очень редких случаях.
Александр, Мой посыл в том, что языку не надо быть популярным. Язык должен нравиться, работа должна приносить удовольствие. А работы в IT везде достаточно, на любом языке и технологии. Количество вакансий не говорит о их качестве. А без качества получаются формошлемы с 10 летним опытом, не понимаюшие почему им не платят высокую ЗП.
Александр, согласно hh.ru вакансий на продавца консультанта в 3 раза больше, чем программиста javascript, и лучше забить на программирование, и пойти работать продавцом.
P.S. на руби очень много проектов и новых и очень больших НОВЫХ тоже много. В прошлом месяце менял место работы, со многоми общался, спрашивал чем занимаются. Много вакансий и много интересных проетов. И уверен, что в джаваскрипте, питоне и пхп точно также. Опытные разработчики не кидаются какашками в другие технологии, и с помощью микросервисной архитектуры используют каждый языкк по назначению, извлекая максимальную пользу.
Melkij А можно ссылочку на предыдущий отве?. В теории никакой просадки по производительности быть не может, но очень интересно послушать про практику, потому как я абсолютно не верю в докер в продакшене и хотелось бы подтвердить или опровергнуть аргументами
У бекендщиков слишком много других проблем которые нужно решить, обычно о том как организовать ссылки не особо задумываются.
Но, как я уже писал выше, Ваш подход вполне имеет место быть. Разве что презентером все таки считается класс, который объединяет в себе сложную структуру данных, а вот вывод этой структуры все же должен быть в своем слое - слое представления
arruah Даже с докер файлом врядли кто-то будет воспроизводить ваше решение локально.
Всего может быть 2 варианта, почему файл не подгружается
1. Он не скомпилировался
2. Он не подгружается веб сервером
Порядок дебагинга такой
1. Открываете консоль сети в браузере, проверяете какие файлы тянутся
2. Заходите в контейнер и смотрите папку public/assets
3. Если там есть эти файлы, самым простым способом будет включить servse_static_assets для рельсы, чтобы убедиться, что все работает
4. Начинаете настраивать NGINX Для этого опять же из контейнера смотрите логи нгинкса, чтобы убедиться что обычные запросы идут в рельсу, а запросы на ассеты отдают статичные файлы
Главное четко уяснить, какой из этих шагов не работает так, как вы ожидаете, а дальше уже искать решения
я бы на этот код оставил 5 комментариев. Потратьте больше времени на изучение основ. И даже не Рейлс, а того как работает веб в принципе. Возьмите какой-то курс годов так 2006, когда еще не было фреймворков и максимально просто и понятно давались основы веба и выучите базу.
Без хотя бы примерного понимания как это работает будет очень сложно
Иван Шумов, У Вас видение ситуации со своей стороны.
Моя практика абсолютно противоположна. Берем джунов, учим. На одну вакансию можем и 5 нанять, если достойный кандидат.
Сама рельса не умрет, пока не появится технология, которая выполнит 2 условия.
1. Разработка на ней будет быстрее чем на рельсе
2. За технологией будет стоять весомая компания, или очень успешный бизнес проект
Крупным компаниям очевидно важнее стабильность, а не скорость разработки, но на единицы крупных компаний есть миллионы остальных и им нужно в основном ruby/php
Быстрая разработка, только у тех кто эту магию хорошо понимает, для новичка будет только все сложнее.
Начните с PHP, там все сильно проще и нельзя сказать что это прям бесполезный опыт. Потом, если вдруг решите выбрать RoR - будет просто понимание что вся магия рейлс это те костыли которые вы из проекта в проект таскали на PHP
Я если честно не понял зачем он добавил первичный ключ в составной индекс и как это относится к физическому хранению данных. Есть паритцирование (в постгресе, не уверен насчет мускуля) которое позволяет данные физически группировать вместе по условию. Но тут явно о чем-то другом речь.
C Windows никогда не работали, в этом просто нет никакого смысла. Даже девелоперу проще vagrant под виндой запустить, чем пытаться разобраться у него все просто не работает, или не работает именно из-за Windows
.env в гитигноре, соответсвенно для девелопмента и продакшена разный.
в гите .evn.example для других разработчиков и по необъодимости описание каждой переменной в readme.md
Тулза для деплоя - mina или capistrano каждый раз подтягивает актуальный .env для продакшен приложения из shared файла.
Что касается деплоя, то он от проекта к проекту разный. Heroku, AWS Beanstaslk, Docker, просто приложение на DigitalOcean или AWS ec2, Rancher или Deis. И получается, что ENV переменные универсальный вариант конфигурирования, который работает везде.
Какую должность занимает тот, который развёртывает приложения RoR?
Как правило, если приложенько простое - Rails + Postgres + Redis + Cron - его настраивают сами разработчики, если сложнее или требуется несколько серверов - инженер из команды DevOps. И там уже он решает нужны ли ему те или иные инструменты вроде terraform, ansible и других или нет.
По факту он отдает в команду разработчиков скрипт или команду для деплоя приложения.
Как у вас налажен процесс синхронизации продакшн среды с предварительными средами?
Такое практикуем не так часто, обычно 2 варианта.
1. Раз в какое-то время синхронизируем базу, при этом обфусцировав данные пользователей
2. Образ докера билдится только для стейджа, на прод заливается тот, который работает на стейдже.
так не смысла писать, есть attr_reader для короткой записи. Или attr_accessor который сразу 2 метода объявляет.
В вашем примере из книги def age=(value) переопределяется потому что внутри есть проверка на > 0
Но, обычно эти базовые методы переопределяют редко. В книге есть просто пример того, что так можно сделать.
Пример, когда это действительно удачно - когда эти методы акцессоры уже определены какой-то библиотекой, которую вы используете, т.е. они уже не стандартные и Вам нужно туда засунуть еще больше логики.
Если у Вас действительно хороший гитхаб, то составте карту-документ с описанием куда смотреть и что там можно увидеть. Иначе гитхаб никто смотреть не будет. Потому что тупо лень ковыряться в чужом недокументированном и неструктурированном непонятно чём.