Евгений

бегает за пивом для старших товарищей

У нас нет уровней, нет грейдов, нет карьерного роста, нет тимлида, нет повышения зарплаты

swagger

1. Правильно ли будет, если на этот сервер разработки я поставлю GitLab?
2. Насколько помню, центральный git-репозиторий обычно хранят на отдельной машине (ну или на github.com).

Вы ни когда не задумывались, с чем это связано? :)

На самом деле, GitLab, не очень "спокойно" работает, если его проксируют, возникает целая череда "танцев с бубнами", что бы он нормально работал. Это первый момент.

Второй момент, напрямую связан с первым - GitLab любит, что бы сервер был целиком в его распоряжении. Если не уходить далеко в подробности, можно поставить GitLab на какую-то виртуальную машину (например, LXC/LXD), а сервер разработки - на вторую виртуальную машину, и всё это будет работать в рамках одного сервера. В этом случае, кол-во "потенциальных проблем" сводится к нулю, но, крайне желательно иметь 2 разных IP, что бы избежать проксирования (и каждой машине выделить свой IP). В ином случае, мы опять упремся в HTTP-прокси со всеми вытекающими...

Ещё один важный - GitLab очень любит ресурсы сервера и обычно требует не менее 1-2Гб оперативки... Которые, разумеется будут "откушены" от сервера и не смогут использоваться другими приложениями. А так же, на сервере будет "паразитная" нагрузка создаваемая самим GitLab'ом и когда кто-то решит выяснить, "почему всё тормозит" - сделать это будет не так просто, как хотелось бы, т.к. на сервере, кроме вашего приложения будет работать GitLab...

Отвечая непосредственно на Ваш вопрос - "можно ли так сделать?" - можно. Но не стоит.

Если западная компания открывает офис разработки в Москве (или в любом другом городе России), то это делается не для того чтобы набрать специалистов и перевезти их зарубеж. Это делается для того чтобы платить разработчикам меньше. Локальные, пусть даже высокие зарплаты в рублях - все равно гораздо меньше зарплат за рубежом.

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

Так что если вы хотите переехать зарубеж - имеет смысл откликаться именно на зарубежные вакансии.

Что не даёт

Есть лишь один правдивый ответ - бюджет.
Если же ПО бесплатное, то рассматриваем бюджет как отрицательную величину.

Минусов много. Основной - не обеспечить целостность данных. И возможности выборки очень ограничены. Лучшее применение JSON в mysql это хранение каких-либо конфигов

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

Попробую расписать на Вашем примере (хранить категории поста в свойстве поста в json) чтобы было понятней:

Тут все отлично пока Вам просто нужно выводить категории у поста.

Как только нужно искать по категории - начинаются проблемы, какой нибудь JSON_CONTAINS - будет дико медленным на нормальном объеме данных (ведь ему нужно выполниться для каждой строки таблицы, а индексов то и нет).

Решение - заводить еще одну денормализованное свойство для категорий - в котором хранить id постов.
Но дальше всплывают новые задачи которые в нормализованной базе решаются за 5 секунд, а в денормализованной - нужно опять же кодить:
- поиск по нескольким категориям сразу
- расчет количества постов у категорий
- итд итп.

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

Я думаю, вообще не стоит получать второе высшее образование, у вас уже нет на это времени. Главное практика. Лучше прокачайтесь сами, напишите несколько приложений и выложите в маркете. Далее устройтесь джуном куда нибудь, с портфолио это будет уже реально. Вот там вы основные знания и получите, без воды и разной шелухи.

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

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

Потому что иммутабельность это вообще хорошо. И обычно, видя енам, ожидаешь, что он иммутабельный.
Чем он аргументирует такой подход?

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

Уменьшать ЗП нет особого смысла - зачем брать более слабого специалиста, который не справится с требуемой работой, даже если платить ему меньше? То есть в любом случае, возьмут того, кто проходит по требованиям, а уж если у него знаний больше, чем требуется - тогда можно попробовать завышать.
Просто overqualified не особо приветствуется, так как считается, что человеку с избытком квалификации на работе попроще будет неинтересно, и он или очень скоро найдет себе другую работу, а значит компании снова придется искать специалиста. Либо наоборот - компания была бы рада вырастить себе специалиста, что дешевле, чем сразу брать дорогого.

1. Возьмите 2 числа.
2. Поделите одно на другое в столбик на листике.
3. Запишите действия
4. Подумайте над ними