В процессе исследований я обратил внимание на доклад Липского, но у меня не получилось на основе этой технологии реализовать одновременное использование разных версий guava в разных сервисах.
Root Service
||
||====> Service A ===> Guava 10.0
||
||====> Service B ===> Guava 33.1.0-jre
Если вдруг у вас получилось с помощью Jigsaw это реализовать, пожалуйста, подскажите пример демо проекта / статьи с описанием реализации.
Я не уверен, что это возможно. Проект Jigsaw, к которому вы вероятнее всего отсылаете, про изоляцию модулей, которая не позволяет решить проблему одновременного использования зависимостей разных версий. Например, использовать Guava разных версий в разных частях проекта.
Возможно, что я ошибаюсь и у вас получится собрать контрпример.
Я думаю, что да. Могу предложить исследовать статью oreilly, посвещенную этому вопросу, https://www.oreilly.com/content/software-architecture-patterns/. В статье представлен общий экскурс в architecture patterns. Надеюсь, что вы считаете это издание достаточно авторитетным.
Но поскольку специалистов по Java на порядок (как минимум) больше, чем на Scala, то Java - отличный кандидат. Может быть, какие-то доли %% производительности по сравнению со Scala и будут потеряны, но зато это с лихвой компенсируется понятностью кода и более низким порогом входа.
На самом деле от разработчика в случае Spark не требуется уметь во все особенности Scala, по факту это лишь DSL для Spark. При этом разработчиков и вообще экспертизы сообщества гораздо больше для пары Scala+Spark, чем для Java+Spark.
Обычно выбор стоит между Scala или Python для Spark. Первый язык предпочитают в случае доминирования в команде DE (Data engineer-ов): на Scala гораздо проще отлаживать код, проще читать сообщения об ошибках; в случае DS (Data science) ориентированной команды выбирают Python из-за популярности этого языка в индустрии анализа данных: большинство библиотек и как следствие проектов используют именно этот язык. Получается, что проще поддерживать проект, который полностью написан на одном языке, чем проект, который использует сразу два языка.
Безусловно, все зависит от контекста. И может быть именно в вашем случае нужен Kotlin / Java / Scala (сразу или по-отдельности, или в произвольных пропорциях).
Это же близкий аналог Apache Hadoop, только с катастрофически малым количеством специалистов на рынке и отсутствием опыта эксплуатации за пределом Яндекс.
Вычисление хеш-функции производится по алгоритму SHA-1 – алгоритм хороший, надежный, известный.
Нет, это не так. В 2022 году sha1 считается небезопасным алгоритмом шифрования (https://cwe.mitre.org/data/definitions/327.html) и следует использовать более надежные алгоритмы, например SHA256.
У всех багов есть severity и исходя из него они идут в спринт. В случае большого приложения количество багов начинает превышать ёмкость спринта (количество рабочий часов разработчиков) и начинает расти бэклог. Задачи с низким приоритетом идут на самое дно и в некоторых компаниях автоматически закрываются, как неактуальные.
Если вам кажется, что разработчик может дополнительно поработать часок, то это только немного увеличит ёмкость и не решит проблему нехватки ресурсов.
Таким образом не критичные баги могут висеть годами.
У AWS есть сервис для тестирования мобильных приложений на различных устройствах - AWS Device Farm (https://awsdevicefarm.info/).
Крупные разработчики сами могут позволить себе такое, например Яндекс (https://habr.com/ru/company/yandex/blog/338038/). Если же у вас нет столько ресурсов, то, возможно, AWS Device Farm (и его аналоги) для вас будут отличным решением.
1. У G много серверов, которые дублируют функционал друг-друга, имеем отказоустойчивость. В случае же хостинга у вас много клиентов, каждый утилизирует немного ресурсов.
2. G сам проектирует ПО для своих серверов и закладывает много ресурсов в обработку отказов нескольких узлов. Не у всех есть ресурсы на построение такой архитектуры.
В последнее время экосистема python показывает значительный рост. Для этого языка есть отличные библиотеки, например, для машинного обучения python значительно удобнее, чем MATLAB.
На данный момент использую ZenMate. Оказалось, что пользоваться очень удобно. Вдобавок ко всему не требует ни каких технических знаний от пользователя.
Пока этого хватает, пока что…
Пожалуйста, дайте совет относительно зарубежных хостингов. Хотелось бы узнать, какая европейская страна лучше всего подходит для переезда? Пожалуйста, поделитесь собственным опытом.
В процессе исследований я обратил внимание на доклад Липского, но у меня не получилось на основе этой технологии реализовать одновременное использование разных версий guava в разных сервисах.
Если вдруг у вас получилось с помощью Jigsaw это реализовать, пожалуйста, подскажите пример демо проекта / статьи с описанием реализации.
Я не уверен, что это возможно. Проект Jigsaw, к которому вы вероятнее всего отсылаете, про изоляцию модулей, которая не позволяет решить проблему одновременного использования зависимостей разных версий. Например, использовать Guava разных версий в разных частях проекта.
Возможно, что я ошибаюсь и у вас получится собрать контрпример.
Нет, это architecture patterns.
Я думаю, что да. Могу предложить исследовать статью oreilly, посвещенную этому вопросу, https://www.oreilly.com/content/software-architecture-patterns/. В статье представлен общий экскурс в architecture patterns. Надеюсь, что вы считаете это издание достаточно авторитетным.
Я понимаю, что есть доклад про использование Spring+Spark (https://www.youtube.com/watch?v=XLSQJQjmFFw ), но это скорее экзотика, чем общепринятая практика.
На самом деле от разработчика в случае Spark не требуется уметь во все особенности Scala, по факту это лишь DSL для Spark. При этом разработчиков и вообще экспертизы сообщества гораздо больше для пары Scala+Spark, чем для Java+Spark.
Обычно выбор стоит между Scala или Python для Spark. Первый язык предпочитают в случае доминирования в команде DE (Data engineer-ов): на Scala гораздо проще отлаживать код, проще читать сообщения об ошибках; в случае DS (Data science) ориентированной команды выбирают Python из-за популярности этого языка в индустрии анализа данных: большинство библиотек и как следствие проектов используют именно этот язык. Получается, что проще поддерживать проект, который полностью написан на одном языке, чем проект, который использует сразу два языка.
Безусловно, все зависит от контекста. И может быть именно в вашем случае нужен Kotlin / Java / Scala (сразу или по-отдельности, или в произвольных пропорциях).
Это же близкий аналог Apache Hadoop, только с катастрофически малым количеством специалистов на рынке и отсутствием опыта эксплуатации за пределом Яндекс.
Нет, это не так. В 2022 году sha1 считается небезопасным алгоритмом шифрования (https://cwe.mitre.org/data/definitions/327.html) и следует использовать более надежные алгоритмы, например SHA256.
Проблема в непонимании принципов семантики Http. GET запрос не должен изменять состояние системы.
Да, есть порт на Python - https://github.com/testcontainers/testcontainers-python .
Вы упустили https://www.testcontainers.org/ , которые позволяют поднимать docker container с нужной бд.
Для ускорения тестов можно использовать mount на tmpfs и использовать backup вместо выполнения миграций на каждый тест.
А на чьих вычислительных ресурсах будет запущено java приложение и бд?
Закрываются они не сразу, а спустя некоторое время. Эту практику можно увидеть в GitLabOrg (пример: https://gitlab.com/gitlab-org/gitlab-runner/-/issues/211).
У всех багов есть severity и исходя из него они идут в спринт. В случае большого приложения количество багов начинает превышать ёмкость спринта (количество рабочий часов разработчиков) и начинает расти бэклог. Задачи с низким приоритетом идут на самое дно и в некоторых компаниях автоматически закрываются, как неактуальные.
Если вам кажется, что разработчик может дополнительно поработать часок, то это только немного увеличит ёмкость и не решит проблему нехватки ресурсов.
Таким образом не критичные баги могут висеть годами.
У AWS есть сервис для тестирования мобильных приложений на различных устройствах - AWS Device Farm (https://awsdevicefarm.info/).
Крупные разработчики сами могут позволить себе такое, например Яндекс (https://habr.com/ru/company/yandex/blog/338038/). Если же у вас нет столько ресурсов, то, возможно, AWS Device Farm (и его аналоги) для вас будут отличным решением.
В этом релизе очень интересно поменяли расположение системных packages, подробнее можно почитать в Issue EnvFile (https://github.com/ashald/EnvFile/issues/140).
Есть же решение от Хабра — https://web.habrastorage.org
2. G сам проектирует ПО для своих серверов и закладывает много ресурсов в обработку отказов нескольких узлов. Не у всех есть ресурсы на построение такой архитектуры.
Пока этого хватает, пока что…
Заранее благодарен.