Да, git pull локально, изменения из репозитория приходят на мою машину, а дальше IDE сама автоматически заливает нужные (изменившиеся) файлы по sftp на сервер. Коммит изменений делается тоже с машины разработчика. По сути, виртуалка нужна только для создания серверной среды и тестирования, на ней самой нет системы контроля версий.
Добавлю, что это дало ряд преимуществ, по сравнению с системой контроля версий на виртуальной машине, из-за интеграции IDE с гитом. Можно смотреть прямо в редакторе, кто какую строку написал и когда. В экплорере подсвечены файлы с конфликтами красным. И так далее. С SVN не пробовал, но думаю, будет точно так же.
Наверняка есть и другие тезисы RESTful, можно описать их полностью. К тому же, дискуссия представляет не меньший интерес, чем сам пост, чтобы понять, что стоит использовать, что нет и какие бывают неожиданности.
Мешает то, что надо лезть в клиент. То есть, заранее должна быть предусмотрена возможность заменить клиенту файл конфигурации командой с сервера (которую ещё не понятно как передать). На практике это похоже на управление толпой луноходов с Земли. А ещё бывают партнёрские и пользовательские клиенты которые тоже очень хочется контролировать. По поводу использования range заголовков для постранички, не могли бы вы пост для хабра написать? С удовольствием прочту.
Преимущество и отличие веба в том, что в любое время можно модифицировать и залатать толстый клиент, мы не учли этой разницы, поэтому тогда и напоролись на пробемы.
Возможно я использую неверную терминологию, команда это обращение к api, а настройки — это параметры вызова, их формат и способ их хранения и передачи в вызов.
В принципе не важно, как хранить, важно где хранить. Если на сервере — то проблем не будет. Представим ситуацию: клиент запрашивает команду getEvents, и передаёт в неё типы событий, которые ему надо отобразить пользователю, и размер страницы. Далее принимается непредусмотренное решение не показывать пользователю какие-то события, или показывать дополнительно новый тип, а так же уменьшить размер страницы на 10 элементов из-за проблем скорости. Если фильтр хранить на клиенте, то без костылей не обойтись. А если для разных мест, где используетя список событий, вызываются разные команды, то нет проблем с модификацией нужного места. Другими словами, клиент должен быть максимально удалён от логики, и быть только представлением данных. Плюс это помогает решить проблему с избыточностью данных, когда ответ универсальной команды слишком обощённый, и делает более гибким http кеширование.
Речь о внешних клиентах — мобильных приложениях. Чтобы их изменить, нужно заставить всех пользователей скачать апдейт. Поэтому тут хорошо работает схема, когда настройки хранятся на сервере, в отдельном адаптере.
AWS сложен сам по себе, особенно для неподготовленного клиента.
Кроме того, есть нюансы по поводу типов системного винта (есть instance-store и ebs, первый умирает при рестарте вместе с инстансом, а второй позволяет выключать и перегружать инстанс, но медленнее и дороже)
«Кликнуть, чтобы купить» не получится. Вам нужно сделать примерно следующее:
Завести учётку, привязать к ней карту с деньгами, сгенерировать rsa-пару для доступа к инстансам.
Зайти в консоль урпавления через меню (сверху) на aws.amazon.com со своей учёткой.
Найти там security groups и сконфигурировать профиль фаерволла для ваших инстансов.
Найти там раздел ec2, запустить инстанс с одним из предлагаемых образов ОС.
Зайти на этот инстанс через ssh (по rsa-ключу, который там называется keypairs) и поставить нужный софт.
При необходимости, сделать из существующего ebs-инстанса AMI (образ) и расклонировать его, сделав кластер.
После завершения вычислений зайти в ec2 и сделать terminate инстансам, чтобы больше не жрали деньги.
Возможно. Есть даже теория, что qwerty(йцукен)-раскладка вообще не является удобной для набора текстов, поскольку разрабатывалась для решения других проблем, связанных с механикой машинок. На хабре было несколько статей по этой теме.
Натравливать ИИ друг на друга с разными наборами юнитов (но одинаковой стоимостью армии) множество раз, оценивая зависимость коэффициента побед от преобладания какого-то юнита. А затем, основываясь на результатах, ослаблять параметры преобладающего юнита (или увеличивать цену) в самых победных наборах. До тех пор, пока не перестанут попадаться однозначно «победные» наборы. Ну это, конечно, при условии, что игра настолько проста, что тактика игры ИИ не сильно отличается от игрока. Дальше возможна такая же схема, но на основе статистики человеческих боёв.