Андрей Шишкин

Сам объект находится в памяти, и все переменные хранят в себе ссылку на объект. Тут скорее наоборот в java проще, потому что нет возможности передачи самих объектов, только ссылки.

А в C++ я могу создать переменную, которая ссылается на объект, могу создать переменную, которая ссылается на область памяти, где хранится объект, могу создать ссылку на переменную, которая хранит ссылку на объект, который хранится в памяти. И память я должен выделять и чистить сам, поэтому в С++ возможно передать ссылку на объект в памяти, который уже не существует, и при использовании вы "выстрелите себе в ногу" с segmentation fault. Как-то так.

Вы будете смеяться, но на мой взгляд, нет ничего лучшего для старта в профессии, чем работа во франче.
Попробую объяснить свою точку зрения.
1. мир 1С насчитывает сотни различных конфигураций. Все их выучить нереально. Значит надо выбрать ту единственную в которой молодой человек станет специалистом. Ну а осмысленный выбор можно сделать только "поварившись" внутри.
2. Кроме языка программирования надо знать предметную область, а это уже та сфера, которая может быть просто неинтересна программисту (иначе он сразу бы пошел учиться на бухгалтера :) ), знания по предметной области тоже лучше получать от разных бухгалтеров, общение с которыми опять же дает работа во франче.
3. Работая одним одинэсником фикси, молодой человек впитывая опыт своих коллег быстро "бронзовеет", т.к. становится "самым умным" среди четырех 50 летних бухгалтеров и потихоньку теряет тот запал для изучения новых конфигураций и прочего с которым начинал работать. Во франче он постоянно самый молодой, потому как все развиваются семимильными шагами, и чтобы догнать тимлида надо много попотеть.
Ну так далее.
Поэтому молодые го во франчи...
А там и литературу посоветуют по той конфе на которую к сертификации надо готовиться и советом помогут.

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

идея проста: процессор, как правило, дешевле памяти, т.к. редко нагружен более 50%, поэтому для кучи проектов дешевле держать один сервер с много памяти, чем несколько серверов (хороший канал, разумеется)

у нас устроено так: nginx на хосте, он же занимается статикой, статика тоже на хосте, а upstream-ы с динамикой (Flask, Django, по-моему bottlepy еще есть) - все в контейнерах, sphinx в контейнере, еще один nginx c сишным демоном тоже в контейнере

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

тут особых наворотов нет - только уверенность в работоспособности других сайтов, если какой-то сложит программер, но вариации могут быть самыми разными - например, nginx с самописными/специфическими модулями в контейнере не ложит остальное, где-то применить Varnish для кеширования, потестить какой-нибудь Aerospike без боязни положить систему и т.п.

СУБД, например H2 (если речь java), или любая, которая нравится.

1. Если в ТЗ было указано на чем делать сайт, то надо было делать на том, на чем указано.
2. Заказчик в таких простых заказах, часто не шарит настолько, что не знает что именно ему нужно. Поэтому у тебя может просто не получиться ему объяснить что не так, и кто виноват.
3. Поздравляю с личным опытом общения с заказчиками. Этот опыт используй мудро, и в будущих заказах старайся предусмотреть развитие странных ситуаций.

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

Использовать систему контроля версий имеет смысл даже если разработчик всего один

Плохо использовать пренебрежительные названия, особенно когда дядька даёт дельный совет, ю ноу. Автор на S.O. имеет в виду, что нужно разделять понятия entry point и application. Т.е., должна быть входная точка, а должно быть и приложение. Отдельно. Плюс такого подхода в том, что лучше соблюдается SRP, а также приложение можно использовать в других входных точках "более чисто": будь то Android или GWT (но это зависит от крутости понимания и реализации ООП), или обычные юнит-тесты. Класс Application можно считать фасадом с точки зрения шаблонов проектирования. JavaFx здесь ни при чём.

----

Заметки на полях

В учебниках стараются писать максимально простой код, чтобы упростить понимание и закрепление материала. Поэтому main(String... args) в таких случаях встречается почти везде.

Битрикс специально создавался таким образом чтобы только их разработчики понимали что за ересь написана в коде, чтобы клиенты не бегали на фриланс