OGSegu, ну смотри. Я вижу 2 решения. Их оба надо попробовать от простого к сложному.
1) Допустим ты копируешь с MicrosoftBlob storage на AWS/S3. Идешь в гугол и ищешь fuse-драйвер для обоих. Ставишь и монтируешь. Появляются два фолдера. И дальше дело техники. Через линуксовую утилиту rsync или через cp копируешь с одного на другое.
2) Разработка. Предположительно тебе понадобятся два клиента. Вот этот для МС https://mvnrepository.com/artifact/com.azure/azure... и вот этот для Амазончика https://mvnrepository.com/artifact/com.amazonaws/a...
Далее ты ищешь разработчика который напишет некий Abstraction Layer над бакетами и фолдерами и файлами и простой функцией скопирует все оттуда сюда. Или отсюда туда. Здесь даже больше возможностей чем в rsync. Можно много проверок сделать. Например фиксировать Etag/SHA1/MD5.
Я написал пример для Java, но можно найти весь стек и под Python.
И то что ты написал про Rest API - это не нужно. Нет смысла ломать головой все двери. Если есть клиент - то используй его. И кстати да. Внутри он написан на RestAPI это правда. Только формат хидеров и ключей там достаточно хитер и нет смысла его в очередной раз реализовывать.
DemPi, ты не поверишь но кодировки - это 80% ошибок всех новичков. Я-бы в ВУЗ-ах ввел отдельный предмет. Под названием работа с символами и байтами в инфо-технологиях.
Реально! Преподаватели и магистры! К вам обращаюсь! Почему из ВУЗов выходят люди которые систематически палятся на кодировках?
На ниве Windows-разработки есть свои графические технологии (WPF, WinForms, Xamarin).
Они прочно занимают место и очень хорошо интегрированы с ядром Windows/.Net. Поэтому
если кто-то захотел делать графику под Windows - то его сначала спросят хорошо-ли он подумал
и почему он вдруг взял Java а не DotNet. Все таки вендор имеет свои преимущества.
В области Linux - царит хаос графических сред. Там даже несколько типов декстопов (Gnome/KDE) которые
друг с другом не совместимы. И там частично это решается за счет Qt либо других С++ фреймворков.
Для MacOS я не вкурсе. Но там наверное что-то своё есть проприетарное и продаваемое за деньги.
Пускай знающие дополнят.
Что осталось для Java? Графические фреймворки AWT/Swing которые пока еще живы но выглядят по разному
на разных ОС. Кто их щас использует - я ХЗ. Но это сегодня явно легаси. SWT - хорошо выглядит и на нем
написаны некоторые приложения типа торрент качалок - но это не чистая Java а следовательно принцип
совместимости может не работать.
JavaFX остался никому не нужной сироткой. Я честно говоря не знаю известных продуктов которые-бы были
написаны и успешно проданы. Если знаете - то скажите.
kuza2000, я не против SQLite. Мне просто надо вникнуть в суть вашей задачи и понять какой класс запросов там бегает. И только после этого я смогу что-то точнее сказать. А пока... берите SQLite.
kuza2000, в твоей активности в топике нету никакого Acceptance Criteria. Тоесть ты не задаешся конкретной целью а просто играешся. В этом случае мы цели никогда не достигаем а просто проводим время в беседе.
Я не специалист именно по SQlite но я тебе хочу сказать что не стоит завязываться на какую-то стандартную библиотеку питона. И то что ты написал по стилю разработки (jupiter/pandas) это не мобильное и не встраиваемое приложение а вполне себе серверное. Значит нечего там экономить на спичках. А SQLite он потому и лайт потому-что изначально делался для in-memory и мобил. А сегодня по нелепой случайности в него грузят терабайты. И всем пофиг. Один я удивляюсь.
ТЗ я себе написал, как мог, а дальше? Планирование архитектуры приложения, базы данных, фронт или бэк?
Чтоб никто здесь не фантазировал. И я не фантазировал. Архитектура разрабатывается только исходя из требований.
Тоесть мы должны прочитать твои требования. Например - в каком виде нужно показать статистику. Эту задачу можно сделать как в 1 таблицу а можно и в 10 таблиц. Все зависит от того что требуется. Нормализация там. Нужно ли хранить историю переходов игроков из команды в команду. Требование? Я считаю да. Что делать если команда сменила название? Заводить новую запись или просто переименовывать? Это - все вопросы архитектуры.
kuza2000, вы занялись очень плохим и неподходящим для баз данных делом. А именно - экономией места. Т.к. вы неоднократно упоминаете "компактность" и "максимально плотное заполнение". Обычно базы данных - не про это. Если у вас - особый кейс - то возможно вам не нужен SQLite а стоит программировать свою собственную (key-value или document-oriented) систему где вы сможете хоть сжимать gzip-пом поля хоть делать column-oriented структуры. Короче я хочу сказать что база данных будет сопротивлятся вашему стремлению ее ужать. Такова ее природа. И многие механики баз данных очень не любят всякие "ужатия".
Но если вы хотите сильно - то попробуйте разбить таблицу на серии. Поскольку у вас загрузка идет сериями - то пускай каждая серия создает табличку. Вы ее уплотняете. И переводите как-бы в Read/Only. В этом случае результат вашего уплотнения хотя-бы сохряняется. В остальных случаях он будет потерян для индексов точно.
DollyPapper, смотрите. Поскольку вы не автор топика - то будет неприлично здесь разводить долгий спор. На тему ООП в Python - вы лучше создайте отдельный вопрос в хабр. Я думаю это будет правильнее.
DollyPapper, Python не способствует дисциплине кода.
Когда ты будешь изучать ООП, которое за собой тащит SOLID, Design Patterns и тому подобное ты просто увидешь что некоторые языки сознательно вводят много ограничений (в т.ч и типизация) и это в будущем помогает читать код когда он разраставется до сотен модулей и десятков тысяч классов.
Читать Python код сложнее т.к. в нем нет ПРАКТИКИ применения типов. Это часто ставит разработчика-читающего в затруднительное положение. Получается что ему недостаточно видеть сигнатуру метода а ему надо вычитать все uses и returns чтобы понять контракт.
И хотя начиная с некоторого релиза аннотации типов введены, сообщество пока не приняло эту практику и можно сказать что % использования практически равен нулю.
Я пересекаюсь с Python мало. Лишь в части Spark/PySpark. И в тех случаях когда надо по "быстрячку наговнячить" запросов к датафреймам. Но самые вкусные фичи (например DataSet) и строгий контроль типов по прежнему PySpark недоступны. И чтобы их потрогать - нужно брать Scala.
В остальном Python - хороший язык и вы можете его смело брать для украшения резюме. Но если вы хотите знать тонкости ООП то вам будет НЕДОСТАТОЧНО использовать Python. Берите специальные языки C++/C#/Java вот шаблоны проектирования как раз писались про них и тестовые примеры как раз тоже с этими языками.
Dmitry Roo, я у себя подозреваю камни в почке и думаю что автору все равно нужен фикс для его исходника. Господин Баелдунг прав в своих примерах - но нужен какой-то специфичный кейс где это применимо и не принесет вреда кроме пользы.
Dmitry Roo, вот вы ему щас дадите совет. А он за чистую монету возьмет и будет всегда все текстовые файлы загружать скопом в массивы байт. Так себе шаблончик.
Drno, если ты решил переключится с работы на игру - то это так себе переключение. Всяко лучше на улицу сходить чем жечь глаза еще больше. Я тоже немало поиграл в своё время. И щас уже вообще не тянет ни разу.
понимаете что такое тип данных?