DIMITREO, в каждом конкретном случае по-разному. Если у вас приложение через API общается с сервером и проще работать через API, то не сильно важно на чем делать бота (js, python, C#), лучше всего подойдёт то, что лучше знаешь.
Многие игры стараются защитить от ботоводства и прочего читерства. Это осложнит написание бота на чем угодно.
Если в вашем случае есть java приложение и нет обфускации, то, возможно, проще будет делать бота на java, а не разбираться с протоколом игры. Но это всё очень по-разному и фрилансерам виднее на чем и как делать бота.
1) жесткие диски сейчас дешевые, софта для инкрементальных бэкапов полно и платного и бесплатного, а вы переживаете, что при блокировке VDS у вас пропадёт единственная копия вашей музыки. Для меня это означает. что у вас нет денег даже на то, чтобы организовать себе бэкапы. О какой инфраструктуре для соц-сети с приличным трафиком может идти речь?
2) ни то ни другое. Просто если диски сошли с конвейера рядом в одной партии и при производстве кто-то открывал форточку, то не вероятность, что накроются два или больше диска разом растёт.
Вот у вас рейд с избыточностью. Вы готовы пережить выпадение одного диска, у вас есть новенький на горячую подмену. Вот этот момент настал и один диск посыпался. Вы со смесью сожаления и гордости за свою предусмотрительность заменяете вылетевший на новенький и RAID начинает его ввод в массив, заполнение данными, избыточно хранящимися на остальных дисках. При этом нагрузка на все эти диски возросла, поскольку продакшн никуда неделся, люди пользуются сервисом, а на обычную активность накладывается еще и нагрузка по заливке данных на замененный диск, который еще не вступил в строй. Массив работает в аварийном режиме и сейчас потеря диска из старой смены повлечет потерю данных. Если диски были в одной партии и лежали рядышком на конвейере, то и ресурс у них очень близкий. А если помер "брат близнец", а на другого "брата" свалилось больше работы, то и он может не выдержать.
3) Мой вариант - это делать бэкапы и держать их на "холоде" (холодное хранилище) - это такое дешевое хранилище с медленным доступом, которое предполагает чтение, возможно платное, только в самых аварийных случаях. Нужно всё аккуратно посчитать, возможно вам дешевле будет хранить это дома. Но помните про все яйца в одной корзине. Шифруйте бэкапы, хорошо промаркируйте и держите диски не в одной квартире, а по надежным родственникам. Мало ли пожар там или потом какой. А-то и омон может прийти по ошибке, а диски и компы забирать они любят вне зависимости от причины захода.
Платя хостингу вы платите не только за мощности, но и за поддержку, замену и ремонт оборудования, за бесперебойное энергоснабжение, за продуманную систему пожаротушения и поддержание ее в рабочем состоянии, за то, что никто не забудет после удачного отпуска где лежат и как пронумерованы ваши диски с бэкапами...
Hcuy, я кому-то, помнится, отвечал на похожий вопрос. По моему скромному мнению академическое образование важнО. Я не знаю какой там у вас бэкграунд по математике, информатике, логике, но очевидно, что знания синтаксиса языка программирования явно недостаточно.
Нужно понимать немного комбинаторику, дискретную математику, основы мат-логики, понимать всё про системы счисления, основы алгоритмизации, конечные автоматы. Поверх всего этого нужно понимать концепции ООП, принципы функционально-логического программирования... А к этому нужно дофига опыта. Нужно постоянно использовать накопленные знания и делать всяких проектов.
Hcuy, в смысле "скакать"? Никто не скакал. То ж в школе и институте. И там далеко не всё, что приходилось трогать по учебе и для себя. По специальности там еще Ada, Haskel, С/С++, всякие там недоязыки типа SQL (хотя тьюринг-полный же=).
По большому счету для работы нужно не много: основной (Python, Js, C++, C# или Java) и SQL. Но знать синтаксис и стандартную библиотеку не достаточно. Нужно понимать всё на абстрактном уровне и в глубину.
да где ж "та же"? В прошлый раз у вас библиотеки не хватало.
Теперь совсем другая проблема, причем специфическая для винды. Ждите, пока эксперты по этой операционке подтянутся. У меня в доступных пределах такой ОС нет уже давно.
Developer, я пишу "обычно" потому, что всегда допускаю возможность каких-то проблем или ошибки. Практика показывает, что большинство проблем с кодировками происходит не из-за плохой поддержки юникода стандартными (или даже нестандартными) библиотеками, а из-за банальных ошибок или непонимания программиста как правильно обрабатывать данные на входе и на выходе.
И избегать кириллических имён в имен пользователя - это "страусиная" политика, полумера, которая не сделает из вас профессионала, не добавит вам контроля и понимания как работает ваш код внутри. Потом мы слышим от таких программистов: "А у меня всё работает". На начальных этапах освоения дисциплины надо не избегать мутных и непонятных тем, а, наоборот, пока есть энтузиазм бросаться на них и до конца разбираться в вопросе. Благо есть ресурсы вроде этого, где подскажут и ответят на конкретные вопросы, помогут понять в кукую сторону копать.
Любой "геморрой" - это следствие прошлой "недолеченной" проблемы. Нужно копать до полного понимания, иначе какой смысл идти в эту профессию? Чтобы быть вечным "шаманом", погрязнувшим в своём культе Карго и не понимающим до конца что как и почему работает, и почему что-то может не работать?
Developer, да что там готовить-то?
Правила простые:
- входящие в прогу строки надо конвертировать из байтов в юникод. Для этого надо понимать в какой они кодировке. Для линукса это обычно utf-8, для винды исторически там зоопарк из cp1251, win866 и utf-8. Но! Если данные поступают из stdin то у него либо указана кодировка (.encoding) - так бывает, если stdin подключен к терминалу или запускается из шелла, и тогда нужно конвертировать из указанной кодировки. Либо не указана - так бывает, если stdin присоединили как pipe, конвейер или файл. В этом случае нужно знать в какой кодировке у вас закодирован файл или какая кодировка на выходе конвейера перед вашим скриптом. Если это всё под вашим контролем, то я советую везде использовать utf-8 и НИКОГДА не использовать восьмибитные ущербные древние устаревшие как окаменевшее дерьмо мамонта кодировки.
На выходе из программы должен происходить обратный процесс.
Надо сказать, что стандартный print и stdout.write получая строки правильно конвертирует их в целевую кодировку, если эта кодировка указана в stdout.encoding. Нужно учесть, что если у вас терминал, куда смотрит stdout в cp1251 или win866, то при всём желании вы туда не сможете записать смайлики, символ рубля и любые символы, не представленные в однобайтовой кодировке. Учитывайте это и делайте явную конвертацию с заменой непригодных символов.
Обычно все библиотеки, которые работают с файловой системой отлично понимают юникод. Проблемы бывает когда им пытаются дать уже закодированные и порой неправильно закодированные строки. Не делайте так.
DIMITREO, а вы искать пробовали?
Я не пользовался, но вот у хабра есть свой проект: https://freelance.habr.com/
Не подходит?