>Имеет ли смысл ставить отдельные виртуалки с ОС для файлообменохранилище, MS SQL Server (express или standart), возможно KMS, файловые базы 1С 7.7 и 8.2
нет не имеет: каждая ВМ — это отдельная ОС (и по лицензиям дорого и по ресурсам)
>для OpenFire
имеет, и лучше всего ставить его на *nix-систему. Хотя Java есть везде.
1. Не смогут взаимодействовать, ибо сети разные. По крайней мере, с точки зрения принтера
4. Если у 2 или больше внешних IP, то шлюз можно сделать как ВМ, тем более у Вас 2 Hyper-V сервера. Шлюз лучше делать на *nix-системе. В идеале на openBSD (ну это если ее знаете).
4. Относительно большой NAS от QNAP нам обошелся в 74 килорубля. Там 4 SATA-диска по 3TB каждый.
5. Лучше всего кинуть оптику (про нее Shajtan ниже сказал)
Тут два похода:
1) пишите на том, что лучше знаете
2) Возможности Java в части серверов огромны (один Jetty чего стоит, если говорить о веб-серверах), а на Qt подобного не видел. Хотя у Вас есть хорошая возможность юзать возможности чистого C++
P.S. Девушка (спец по Qt) говорит, что есть QTcpServer.
С зависимостями все хорошо: они в папке lib и classpath'e. Тут вопрос в другом. Как быть с папкой bin, которую очень не хочется кидать в гит до деплоя на боевые сервера. Плюс собирать на ноуте тоже не хотелось бы, но тогда eclipse ругается.
Значит, что Вы хороший разработчик. Я лично тоже максимально хорошо комментирую код, чтобы потом с легкостью генерились JavaDoc'и.
Но в нашем мире не все умеют писать хороший код.
А можно ли так сделать, минуя назначение IP-шника на физическом адаптере ESXi? То есть так: ---NIC--VM_NIC(X.X.X.X)? И как тогда будет выходить на L2 (с какого MAC'a: VM_NIC или физического NIC)?
Скорее всего. Я сейчас позвонил в гугл они сказали, что эта хрень «оплатой» nexus'a была authorization pay, а окончательно они снимут деньги когда будет shipping. То есть как в письме написано 5-6 недель
Для меня Python весьма не привичен из-за его тяги к функциональному программированию и не C-подобности.
Опять же закат Java маловероятен, так как этот язык выбрал Google для своего андройда, а так как они заинтересованы в платформе, то язык тоже будет на плаву.
Для JavaEE надо: IDE (оно нормально работает и с NetBeans и c Eclipse for JavaEE)+JVM. Так как в EE-шных версиях IDE-шек многие компоненты весьма удобно интегрированы в саму среду разработки.
Пока наиболее востребованные фреймворки — Hibernate и Spring.
Alexufo: «нет дебагера» — как раз он есть: xdebug. Фреймворки (особенно Yii) — это хорошо, но много PHP-кода во View'шках. Большие команды больших проектов «пишут с нуля».
Про Xamarin: я не думаю, что выстрелит. Я столкнулся с Xamarin, когда мы в Бауманке изучали C# и хотелось нечто для практики, но Windows-машину было ставить лень. Мои впечатления: Xamarin — это платный Mono. И еще мне кажется, что .NET, без прямой поддержки Microsoft, обладает только теоретической кроссплатформенностью, так как полная реализация .NET+CLR есть только на Windows. Здесь я могу ошибаться, так как только поверхностно знаю кухню .NET.
Java: сейчас на ней в основном пишут серверное ПО (Банковское и подобное) или, опять же, под Андройд (за этим стоит Google, который сравним по масштабам влияния с «одной компанией из Редмонта»
Про Android: все уже описали выше, я с этим согласен. Еще могу добавить, что привлекает: 1) перспектива — оно будет развиваться. 2) лекость локализации приложений.
Про PHP: оно не сдохнет в ближайшие N лет, так как на весьма крупные вещи написаны: тот же VK.com и Facebook.com (для минусующий: я знаю про компиляцию кода в С++). Плюс языку есть куда развиваться.
Но переходить туда Вам не советую, ибо:
1) много работодателей, которым нужен комбайн по клепанию сайтов, а не толковый программист.
2) уровень зарплат меньше, чем в Java/C#/C++ мирах при похожей нагрузке
3) сам язык.
Последнее поясню. После C# многого будет не хватать (сужу по себе):
а) статическая типизация реализована частично (есть для объектных типов и для массивов).
б) массивы: это не массивы, а ArrayList и HashMap.
в) нет boxing/unboxing, так как нет нормальной типизации, хотя бы опциональной.
г) нет перегрузок функций (опять из-за типизации). И как следствие надо в каждой функции проверять тип входящего параметра.
д) нет общего для всех объекта (Object): иногда бывает полезен при наследовании.
нет не имеет: каждая ВМ — это отдельная ОС (и по лицензиям дорого и по ресурсам)
>для OpenFire
имеет, и лучше всего ставить его на *nix-систему. Хотя Java есть везде.
>Эта цена вместе с дисками?
Да, вместе с дисками