Где искать заказы java-разработчику (web, энтерпрайз)?

... тем временем, шел 4й год со времени громогласного прогноза об издохшей джаве...
джава прододжала дохнуть и дохнуть...
... включена в штатный дистрибутив астра линукс, выпущена гос-джава.
а хомячки продолжают мечтать про сишарп.

это все чть вам надо знать об "убийцах джавы" ;)

Отношение ПС к автогенерируемому контенту?

у вас есть пресейл-демо сервер?

Какие книги прочесть на тему того, что сотрудников нельзя эксплуатировать как роботов по 8 — 12 часов в сутки и 5-6 дней в неделю?

Вадим Соловьёв, плейстейшена у меня действительно нет, и наврятли будет.

равно как иксбокса, свича и др. не угораю я по приставочным играм.
игровой ноут стоимостью "3 макбука" с core-i7 8го поколения ( так сказать "и для работы и для игр") - мой выбор.
а приставок меня нет, и не будет.

ps: и еще одно. я как раз ТОТ чувак, который может приходить на работу и в 9 утра, и в 12 по желанию.

Какие книги прочесть на тему того, что сотрудников нельзя эксплуатировать как роботов по 8 — 12 часов в сутки и 5-6 дней в неделю?

Вадим Соловьёв, ну во первых, исходная фраза принадлежит не лебедеву;

во вторых, фраза была про то, что "руками" должна работать машина, а человек должен работать головой;

а в третьеих, - вот вы на него, на этот процессор, сначала заработайте, потом запрограммируйте. а потом, если вам кто-то будет согласен давать деньги за то, что он "потеет" - сидите играйте в плейстейшен и восхваляйте Лебедева.

как то так.

Какие книги прочесть на тему того, что сотрудников нельзя эксплуатировать как роботов по 8 — 12 часов в сутки и 5-6 дней в неделю?

Вадим Соловьёв,

Но ведь google и другие крупные корпорации уже внедряют эти инновации.

Вы пожалуйста не смешивайте желание "нифига не делать и играть в плейстейшен" со "взаимоотношения с высококвалифицированными специалистами".

Прежде чем вы сможете устроиться в гугль как специалист, с которым будут носиться как с писанной торбой, вы должны въ***ть, въ***ть, въ***ть, и ещё раз въ***ть. и часто при этом грызя гранит науки бессонными ночами.

А если вы хотите что бы вам позволяли играть в плейстейшен но сами при этом нифига и никак не полезны - вопрос - а вам кто обязан чем? )) работодатель не обязан вам ничего сверх того, о чем вы договоритесь. И если вам нечего предложить в качесвте услуг - никакого плейстейшена у вас не будет.

Переход с Angular на React. Тренд или нет?

sim3x,

Вы пытаетесь меня убедить, что тем кто пишет на жс
- знать жс не нужно
- знание жс приводит к написанию лапши

не надо "навешивать на меня ваших крокодильчиков" ))) я такого не говорил.

js знать надо. но не не надо писать на нем все подряд и (как правило) не надо писать на нем очень большой код. (это не отменяет полезности и необходимости компонент с законченной фиксированной логикой которая не меняется - таких например как Leaflet, Codemirror и др.)

само по себе знание js не приводит к "джаваскрипту мозга" и лапше.
к лапше приводит "зацикливание на js", фанатичное горение в глазах и погоня за постоянно сменяющими друг друга идеологиями разработки и фреймворками - просто в силу того, что они "последние".
увы, именно эти симптомы и "знание последних фреймворков" многие сегодня принимают за "знание разработки на js".

Переход с Angular на React. Тренд или нет?

msdosx86, нет, это не жесткое легаси)) есл конечно вы имеете в виду под легаси "наследованные системы и обратную совместимость со старыми технологиями". ничего такого, просто "большие интерпрайз" системы, которые должны "просто работать". а вы - на протяжении пары-тройки лет развивать их и фиксить найденные баги. ничего "наследованного" - вы сами выбираете технологии и сами потом имеете с ними проблемы в последующие 3-5 лет.

и что значит "глупо"? ) почему именно "глупо"? т.е какие технические проблемы вы видите?

мы вот (в нашей области, конечно) видим технические проблемы с "толстым js", в который скриптеры рано или поздно начинают впихивать бизнес логику, что приводит как минимум к 2м серьезнейшим проблемам в армах :

- js код становится не подъемным и его крайне проблемно поддерживать и рефакторить (из за динамической типизации невозможно автоматически отслеживать, что ты поломаешь, на какие именно функции повлияет очередное исправление функции в апи);

- бизнес логика начинает выполняться на клиенте, а это приводит или к постоянным попыткам передать на клиент данные которые на него нельзя передавать (логика действий часто завязана на данные которые пользователю не доступны, а безопасность и ограничение доступа никто не отменял), или, из за необходимости проверять действия пользователй на сервере (см пункт 1) крайне сильно усложняется обмен данными между клиентом и сервером. а последнее не только само по себе приводит к сильному усложнению кода, но и крайне плохо влияет на рефакторинга, не только потому что "см пункт 1", но и потому что число рест сервисов на сервере начинает расти лавинообразно, а т.к. зависимости между между вызывающими и вызываемыми функциями "не явные", их технически контролировать нельзя (примитивно- нет аналога wsdl и кодогенерации которая бы просто не дала бы тебе собрать код пытающийся вызвать несуществующую функцию ) - то поправляя очередной баг в рестушке ты не знаешь где в каких именно, местах какими ajax запросами она вызывается и какая часть клиента в итоге отвалится. отследить связи автоматически не выходит (см чуть выше - нет таких технологий в js/ajax) а ручной контроль на таком объеме кода сбоит .

это опыт последних лет 5и. мы сами писали, мы наблюдали как живут и развиваются продукты партнеров, анализировали причины проблем, возникающих при поддержке и развитии этих продуктов.

потому сегодня, в новых разработках мы и стараемся максимально избавляемся от джаваскрипта. вернее мы используем js так, как это положено - скрипты не тяжелее 1й страницы.
за последение полгода, в новом арм, мы написали от силы пять сотен строчек js кода. никакой бизнес логики, только управление view и анимацией. и оно работает, и вполне соответствует требованиям динамичности выдвигаемым к одностраничникам.

а почему ВЫ считаете, что полагаться на бакенд и jquery - "глупо"? и в каких случаях?
(ps: я повторюсь, что мы делаем не публичныые массовые сайты, а тяжелые логикой бизнес-армы с ограниченным числом пользователей)

Переход с Angular на React. Тренд или нет?

sim3x, я сказал что не нужно то, что ВЫ имеете в виду под "писать на js".

вот я наприиер знаю js. пишу по мере необходимости.
где то мелкие оберточные скрипты и логику уровня "поведения view". и считаю что я умею писать на js.
но делать лапшеобразную разъезжающуюся во все стороны мешанину из обрывков бизнес-логики в перемешку с сакральной работой очерелных сформированных в рантайме костылей..., которые генерируют среднестатические "джаваскриптеры головного мозга"... извините.

ну так вот - очень показалось, что вы, по всей видимости, относите этот уровень владения js к "не умеет писать на js". вот я и спрашиваю - может "оно и не нужно?" - не нужно травмировать себе мышление бесчисленными попытками перепрыгнуть лимит технологии?

что вы имеете в виду под "уметь писать на js" ?)

Переход с Angular на React. Тренд или нет?

. А если проект уровня 50-100К долларов, то тут ни о каких жиквери речи нет.

а если я вам скажу что мы создали технологию, позволяющую на Java + jQuery + "немного примитивного js" делать "динамичные интерпрайзные армы с тяжелой логикой" стомостью гораздо больше чем 100КЕвро ? что вы скажете?))

Переход с Angular на React. Тренд или нет?

sim3x, а может, оно подавляющему числу разработчиков и не нужно?
именно то, что вы имеете в виду "уметь писать на js"? ;)

согласитесь, что джаваскрипт головного мозга накладывает серьезный отпечаток на способности разработчика и он (js головного мощга) практически неизлечим ))
равно как и приводит к его практической неспособности писать качественный код на промышленных языках (имхо) и понимать архитектуру больших систем.

джаваскрипт из инструмента быстрого скриптования, призванный решать проблемы - превратился в скопище сакральных технологий, перегруженное темной магией чудовище, переоцененное, которое еще к тому же, пытаются пихать куда ни попадя.
и это мягко говоря уже начинает подбешивать.
не говоря о значительном удорожании стоимости проектов, и стоимости поддержки проектов написанных с "толстыми клиентами на js".

а jQuery как раз пытается эту простоту сохранить - он дает простой и унтуитивно понятный инструмент, без мозгосносныхых "супер подходов и концепций", и без темной магии типа "а тут оно само обновляется" и тд и тп..
может именно поэтому он популярен и не собирается уходить на свалку истории? ;)

Переход с Angular на React. Тренд или нет?

sim3x, ага. видели, знаем.
только вот одно мне не дает покоя : весьма очевидно, согласитесь, что само по себе появление статьи на эту тему говорит само за себя - от jQuery никто особо отказываться то и не собирается. он жил, жив, и будет по всей видимости живее всех других "прогрессивных фреймворков".

имхо, потому что он справлялся, справляется, и очень похоже будет продолжать справляться с 90% задач, которые ставятся перед разработчиками подавляющего числа сайтов. )

Существуют книги с примерами, которые рассказывают, как правильно проектировать ПО?

>>у нас есть задача, вот у нас есть паттерн, верно?

точнее "у нас есть класс задач, и вот мы знаем несколько паттернов проектирования, которые относительно хорошо себы показали при решении такого рода задач". и далее идет описание шаблонов (структурных или поведенческих), плюсы, минусы, возможности и ограничения каждого из вариантов.

по книгам посоветовать пока наверное не смогу.
мы читали в свое время вот это, возможно скорее всего уже в продаже не найти (под спойлером большая картинка) :

spoiler

но поиск в яндексе выдает (вроде как ) пару сайтов , которые (как минимум на первый взгляд) не несут особой пурги:
* https://refactoring.guru/ru/design-patterns
* https://tproger.ru/translations/design-patterns-si...

На чем писать веб приложения с GUI как в desktop app?

Как нет, в ASP.NET давно написана обертка для них, SignalR. Пользуйтесь на здоровье.

mletov, я не про обертки над вебсокетами.
я про то, что нет промышленных решений, которые используют вебсокеты для работы с гуи, максимально сближая веб интерфейс и бакенд. идеальным я виже технологию, которая управляет веб интерфейсом по принципам мало отличающимся от того, как например Qt работают со своими формами.

Прочитал, но так и не понял, чем современный подход на REST принципиально не подходит для написания
СЭД (системы документооборота), арм различных госструктур, арм различных операторов, и тд.

а это и не объясняется в самом тексте )
в общем случае, есть несколько моментов, каждый из которых может быть и можно рассматривать как мало значимые, особенно на малых проектах (все так живут, действительно), но вместе они приводят сложные проекты к серьезным проблемам :

1. используя аякс запросы затруднительно организовывать сетевое взаимодействие вебморды и серверной части. особенно в сложных сценариях требующих реализации "протокола обмена с состоянием" на обоих сторонах - например пошаговый "мастер-чего-либо" или хитрые проверки разных условий ... когда вы будете писать сложную интерактивные формы - у вас всегда будет копитьсяч ворох мелких проблем который постоянно будет норовить встать вам поперек горла комом шерсти, мягким комом, но которым вы, тем не менее, подавитесь.
(я не говорю что это нельзя или невозможно решить в аякс|рест механизмах, можно, но это не самая тривиальная задача в разработке и не самая тривиальная задача в отладке - как на сервере так и на клиенте, и она решается... но увы с рестами и аяксами - это никак не дешево и совсем не быстро... )
async/await конечно облегчат вам жизнь на клиенте, но что вы будете делать на сервере, когда вам по сценарию надо будет в определенной точке алгоритма отослать ответ, а потом ждать очередной запрос от клиента, что бы ответить ему используя ранее полученные данные ? наверное, писать свою асинк-обертку над ожидателем запроса|хердлером|ещеЧем-то что будет разбирать поступившие после идентификации пакеты и раздавать их ожидающим. очень хороший рест-"сервис", ... "и конкурсы интересные", да ? )) не удивлюсь конечно если для "спринга" есть такой модуль "сетевого-диалога-овер-аякс";
Но у аякс запросов так же и куча доп. накладных расходов , и технических ( ради каждого запроса поднимаете отдельное соединение , что банально жрет время и трафик - только на одни http заголовки у вас до килобайта уходит), и организационных ( каждое подключение надо идентифицировать и авторизовать, и передать пакет туда куда нужно - там где ждут ответный пакет от клиента, или тнадо найти серверный объект который хранит состояние клиента сейчас ) - т.е. у вас банально уходят ресурсы на восстановление контекста или сессии в котором надо выполнить этот запрос. это и на сервере и на клиенте.
(в случае же локально-десктопной парадигмы такой ситуации попросту не возникнет - ваш алгоритм не разорван на клиентскую и серверную часть - все выполняется на сервере, а клиенту уходит только отображение - как это сделано в Qt или старательно эмулируется в jsf)
тут надо отметить еще, что где то у node.js есть технология поддержания на сервере актуальной веб-старницы и синхронизации этой страницы на клиент по мере ее изменения. видимо авторы node.js не только отгребли проблемы с js, но и успели вляпаться в проблемы с рестами...))) хотя их вариант решения мне не очень нравится - синхронизация - это достаточно поганая и сложная штука если она сложнее простого семафора илти обмена рапой записей.

2. жизненный цикл приложений построенных на рест стремится к обработке данных на клиенте. сам по скбе рест сервис этому способствует. это передача данных клиенту, обработка данных на клиенте тяжелым js, передача данных на сервер. на этот цикл у вас завязано 99% всех актуальных js-фреймворков. посмотрите например на ту же компоненту типа handsonTable - она не держит на клиенте только "отображение". вы сгружаете клиенту полный объем данных, он их жует-редактирует и потом вы всю пачку пытаетесь отослать на сервер и там прожевать.

3. в силу пункта 2 - в подаляющем числе случаев у вас бизнес логика начинает выполняться на клиенте.
это приводит к 2м негативным последсивиям :
3.1 : код на клиенте сильно усложняется, что в силу динамической типизации js приволит к проблемам рефакторинга (хотя это можно пытаться нивелировать разарботкой на typescript с последующей трансляцией в js, но typescript далеко не самая распространенная технология)
3.2 : начинается расслоение бизнес логики многих "атомарных" операций на сервер и клиент., т.к. вы не можете выполнить все на клиенте, и вы будете вынуждены разрывать многие "единые операции с точки зрния логики" на 2 части - клиент и сервер. просто потому, что вы не имеете права отгрузить клиенту некоторые данные в силу требований безопасности (и отгрузить но не показыыать тоже не вариент - помните, что клиенту доверять нельзя - пользователи знающие про F12 найдут много интересного). в итоге вам надо усложнять сетевое взаимодействие. в жтот момент также вспомним про пункт 1 (о сложностях организации сложного сетевого взаимодействия с аякс) который умножает эту скорбь.

4. в силу того, что вебморда и задник "слабо связаны", рано или поздно вы начнете терять зависимости между тем какие сервисы какими веб-интерфейсами используются. т.е. вы получате проблемы аналогичные динамической типизации на большом проекте - изменив что то одно, вы далеко не всегда в состоянии предсказать на что это повлияет - что перестанет работать.
ситуация усугубляется тем, что в силу пункта 3 (у вас сложная бизнес логика разорвана между клиентом и сервером, и вы должны её постоянно сшивать ) вы вынуждены создавать вск новые и новые функции и рест сервисы. а в силу желания повторного переиспользования сервисов ( что вполне понятно ) - это приводит к тому, что у вас связи между элементами формы на веб морде и рест-сервисами в бакенде - в подавляющем числе случаев начинают приобретать характер все-ко-всем. и в итоге ваша система на полном ходу вваливается в ситуацию когда у вас все разваливается при малейшем изменении.

вы можете пытаться модерировать и отслеживать эти зависимости, и наверное даже это некоторое время у вас будет получаться, но это затраты времени, которые сильно замедляют любые работы по модификации системы.

вот и получается, что современные массовые подходы к веб-разработке мало пригодны для сложных бизнес-систем.

парадигма разработки "а-ла десктоп" в первую очередь убирает пункт 4 (слабая связь между интерфейсом и кодом его поддерживающим), полностью убирается пункт 3 (бизнес логика на клиенте), пункт 2 (обмен данными между клинтом и сервером) исчезает и становится обменом сигналами и небольшии кусочкаи для отображения на клиенте а пункт 1 исчезает почти пошностью, потому что у вас "как бы нет обмена данными между клиентом и сервером" - все элементы "как бы локальны".

но вот нет хороших промышленных решений работающих по этим принципам. есть c++/qt и их трансляция формы в веб. есть java и jsf, в варианте какого нибудь там primefaces, вроде как есть vaadin, но как я понимаю, это фактически перекомпиляция java в js с полной отгрузкой приложения клиенту (что малопригодно в ситуации недоверия клиенту).

хорошо смотрится jsf, но вот нет вот аналога jsf но способного работать с html, открытого для интеграции в него имеющихся наработок и компонент на js ( иногда жто действительно надо - посмотрите на тот же leaflet, code mirror и др).

ps: прошу прощения за опечатки - писал с планшета, периодически промахиваясь)

На чем писать веб приложения с GUI как в desktop app?

В контексте вопроса - дотнет кор тоже не решает вопросы связанные с тем "как писать веб-приложения как будто для тдесктопа". Или решает?
Что они предлагают для того что бы не городить "частокол костылей rest-сервисов" ?

-----------------------------------------
>> Unity это самое худшее для чего подходит шарп.
но тем не менее это едва ли не единственное что серьезно выстрелило в области "C#-и-иже-с-ним".
с обратной совместимостью у шарпов проблемы - потому писать большие интерпрайз-системы на шарпах опасно. Слишком много надо будет переделывать после очередной смены моды и выхода новой версии компилятора.
И вот сейчас - опять же - они снова устроили революцию. Выпустили core. Сколько надо человеколет на то что бы переветси на core средних объемов корпоративную систему?

>> вышел мультиплатформенный .net core.
лично я в эту "мультиплатформенность" не верю, вы меня извините.
но это моё имхо, основанное на факте, что старый дотнет тоже заявлялся как "мультиплатформенный",
а на практике таковым ни разу не являлся.
что предъявляли? предъявляли mono. на котором мало что собиралось и работало.

core конечно заявляется как мультплатформенный, но тому предложению "без году неделя".
и в условиях исторических фейлов майкрософта - я бы не стал так уж браво это пробовать. поиграться - да, но не больше.

Хотя если у вас нет выбора и с шарпов вы уже не сможете слезть - "только этот путь у вас и есть".
Но если выбирать между джавой и новым дот-нет-кором, я бы настоятельно рекомендовал джаву.
А на дотнет-кор стоит посмотреть через годик хотя бы - когда он пообкатаннее станет,
вскроются (или нет?)) ) все проблемы с его "кросплатформенностью", когда среда пообкатаннее станет, да фреймворков и подсистем чуть побольше создадут.

Если действительно нужна мультплатформенность - на десктопе+мобилки - внастоящее время лучше C++\Qt освоить.

Чем заменить JSF(primefaces)

Руслан Лопатин, имхо, вы просто ещё не прошли стадию отрицания одной важной истины :
"js+rest нелья приготовить правильно" ))
Вернее можно, но только небольшие закуски.

Сложный интерпрайз и разного рода АРМ операторов всех мастей делать на рестах и джейсонах - крайне рискованное дело. Настоятельно не советую. Трудозатраты и сложность после определенного момента сложности начинают расти совсем не линейно.

В случае сложной логики, которая присутствует и на клиенте и на сервере, вовсе не нужно её повторять и там и там.

Я говорю совем не про логику которая присутсвует "и на клиенте и на сервере", не упрощайте)

Я говорю про логику, которая не может присутствовать на клиенте.

Про проверки, которые можно провести _только_на_сервере_, но необходимость в которых возникает в рантайме при обработке на клинете, и которые надо "вплетать" в логику работы клиента.

Напрмер, вы не можете реализовать эти проверки на клиенте, просто потому что клиенту нелья показывать эти данные - т.е. данные с которыми вы сверяетесь нельзя сгружать на клиент. Или вы банально не можете это делать на клиенте (например, вам надо зарезервировать коды в БД в процессе редактирвоания табличных данных).

Делать это "правильно и красиво нарестах" (как вы предлагаете, как я понял) - будет очень сложно и долго. При первом-же рефакторинге эта конструкция у вас развалится, потому что вы банально не вспомните за что отвечает каждый из трех сотен созданных вами рестами, и где какая форма отвалится, "если поменять вот этот рест".

Чем заменить JSF(primefaces)

Не согласушсь.
И попрошу автора быть менее категоричным ;)
Вы просто не видели в какой "содом и гомору" может превратиться попытка развивать систему построенную по приницпам "толстый js + rest_сервисы" если у вас сложная бизнес-логика.

т.е. построить то вы это построите, но потом начнется такой ППЦ когда вы начнете навешивать на это сложные проверки и валидации, особенно если они связаны с чем-то что надо провреить на сервере (например, вы назначаете номер, и надо проверить соответвует ли этот номер тому, что уже есть в системе - в базе, и если есть - то надо будет пересчитать соседние номера элементов по хитроме алгоритму - например вы всавляете элемент в середину иерархического списка, и номера надо раздвинуть)... и пересчитать на клиенте вы не можете, потмоу что пересчитывать надо из нескольких мест в нескольких формах и событиях.

Вы скажете что что тут сложного? сложного в одном запросе - ничего. Но когда у вас десяток таких условий только на одну форму, то вы просто напрость потеряете хвосты того что где кончается когда начинается и что за что у вас отвечает. У вас очень быстро потеряется зависимость между формами и рест-сервисами (т.е. глядя на рест сервис вы не сможете точно скзаать какие из 50+форм системы у вас вызывают этот сервис, и какие куски процессов он поддерживает, потому вы быдете очень сильно очковать его менять)...

В общем в тяжелых случаях, ув. tsegorah - поверьте, есть очень большой смысл выносить логику работы формы на сервер, поверьтте мне. Вас просто проклинать не будут те, кто будет это развивать и поддерживать.

Почему нормальные ОС не делают для смартфонов?

syxoi: йоу, йоу, парень, палехче! не кипятись)))

1) если все так красиво как ты говоришь, то почему же ситуация именно такая, что ты задаешь свой исходный вопрос ?)))) тут 2 варианта - или ты что то упускаешь, или есть ещё что то третье.

но имхо :

2) именно те 2 отличия которые ты с легкой руки отбросил ("кроме архитектуры и кол-ва ресурсов") - они и определяют все. или почти все.
2.1) ....начиная от драйверов (где там статистика сианогенмода по поддержке железа на том или другом оборудовании? на моем "галакси ноут 2017 едишен" поддержку стайлуса запустили? нет?почему? ) почему самсунг не делает опенсорсных драйверов на свое железо - это отдельная песня. конкуренция и тому подобное. сегодня скопировать железо легко. софт что бы железо заработало - часто сложнее.

2.2) ...и кончая спецификой программной архитектуры (структуру активити андроидного приложения знаешь же?). говоришь нельзя заменить одну фс на другую? ты же в курсе, что поддержка полновесного универсального программного интерфейса - в данном случае - к драйверам фс - со всеми их спецификациями - не самое дешевое удовольствие? а у нас - что? правильно. ресурсы ограничены. и память, и вычислительная мощь. и так во всем, по всем подсистемам. все урезано до минимума.

сравниваешь с малинкой? а сволько твоя малинка жрет ? полампера , ага? т.е. от стандартного 3 ампер-часового аккума она будет жить 6 часов? конкурентноспособно для телефона? а если начать уменьшать тактовую частоту, энергопитание, да производительность, да менять принципы работы с железом - и что бы питанием их управлять и режимами работы - она начнет глючить и/или тормозить (потому что "нормальная" как ты выразился , ос не приспособлена жить в таких условиях.) имхо.

это аналогично тому, что "никто же не делает 'нормальные ос' для встраиваемого и бортового оборудования" есть специализированные ос реального времени разной степени жесткости. вот и тут так же. я вот не верю, что убунту-фон не взлетел только по политическим причинам.

Есть ли интерпретатор Java без среды, по типу консольных?

offtop: если судить об идее по андроидстудии, то в идее до сих пор нет внятной навигации по внутренней структуре анонимных классов, что добавляет очень много геморроя при отладке сложного кода с кучей "обработчиков". так что нафиг эту вашу идею. с эклипсом помучаемся ))

Соблюдаются ли авторские права на сторонних android/ios сторах?

Ну в принципе так и будет))) только у вас (в случае музыки) это будет производное произведение. А насколько производное - плагиат, ремикс, или ещё что, и главное - насколько это нарушает лицензию исходного произвдеения (а так же то, насколько лицензия правомочна накладывать на вас те или иные ограниячения) - в случае чего будет разбираться суд )))

и ещё, имхо, тут нужно различать какое именно проиведение вы "повторяете". Ещё есть некое тонкое понятие типа "проиводное произведение".
В приведенном вами случае - именно музыка - точто вы "сыграете на слух" - помня оригинал - будет производным произведением, типа ремиксом. А в случае книги "Приключения Тани Гроттер" (видели наверняка) - доказать что это - плагиат, созвучное название охамевших недописателей или самостоятельное произвдеение не связанное со "шрамированным магом в очках" - сложно.

В случае файлов с картинками - вы однозначно не можете скопировать файлы или их содержимое. Ни принтскринить, ни копириовать иным образом. Но вы можете сесть и нарисовать свои картинки. А если они будут очень похожи на оригинал -
тут в тоже "суд будет решать" является это вашим сосбтвенным произведением или нет.

Вообще, в этом контексте вспоминается всем известный "Кот Саймона". Помните? так вот. Персонаж хороший, а владельцы - ... не очень))) копирасты похожу ещё те. Причем в самом плохом смысле этого слова.

Видимо они решили, что теперь, любой кот, нарисованный карандашом - есть копия их кота саймона и нарушение их "аффтаксских-прафф". И подали в суд на разработчиков "Котухи" ( https://www.youtube.com/watch?x-yt-ts=1422579428&v... )(не сочтите за рекламу).

Ну в общем Котуха - это не кот Саймона, а копирасты были посланы в освояси.

Что я хотел сказать - что часто все зависит от степени маразма того, кто владеет авторскими правами. Ну а вы тоже не наглейте, и не пытайтесь прокатиться нахаляву )) Все тонко и чатсо решается договоренностями.

Соблюдаются ли авторские права на сторонних android/ios сторах?

KislyFan: лучше потратьте время и нарисуйте свою графику.