Обновить
19
0
Олег @dopusteam

Разработчик

Отправить сообщение

А есть нормальные аргументы, а не холодильники?

Не совсем понимаю пока логики ваших слоёв и их зоны ответственности

Ещё вы упомянули DDD, а где у вас доменная логика будет?

Наоборот такая вложенность гарантирует нам то что каждый слой сервиса будет работать атомарно не нарушая принцип работы другого сервиса

Непонятно, если честно. Есщи б у меня репа сразу запрос слала, то что бы я проиграл?

Не зря говорят, что любую проблему может решить добавлением слоя абстракции, кроме проблемы большого количества слоёв. На практике, при изменении придётся менять сразу все слои, что в поддержке неудобно. По моему опыту.

Так что кажется наоборот, такая вложенность гарантирует, что слои атомарными никак не будут

Вам не кажется, что получилась слишком большая вложенность?

Store -> useCase -> repository -> apiService?

Не хватает вообще какого то резюме, что в итоге получили, удобство поддержки, там, или простоту.

А ещё

new TodoModel().from(json)

Выглядит странно, имхо. Либо уж через конструктор, либо статический метод fromJson кажется было бы лучше

Изотоп героя

P.S. понятно, что опечатка, но показалось забавным

Распространенными языками API являются REST и SOAP.

REST и SOAP - это языки?

взаимодействует с базовой базой данных

Документация — встроите защиту непосредственно в документацию по API, чтобы разработчики с самого начала понимали правильное использование.

Чего?

А вы перед заходом на сайт тоже разрешения спрашиваете?

Спасибо за ссылку, но кажется не всё так однозначно)

So, even if you are not the owner of a work, you still may be able to use it

https://www.copyright.gov/what-is-copyright/

По крайней мере, я б не рискнул вот так просто утверждать, что в данном случае это является воровством

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

очевидно - это конечно хорошо, но давайте всё таки по делу, вы утверждаете, что это воровство, но не приводите никаких аргументов, кроме очевидности.

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

Это не воровство.

Не игнорируйте, пожалуйста, мой вопрос

Я оплатил сто долларов за хостинг. Из них 20 потратилось на показ моего сайта в чужих фреймах. То есть кто-то украл у меня 20 долларов.

Если я захожу на ваш сайт, я тоже ворую ваши деньги?

то у копирующих 

Никто ничего не копировал, насколько я могу судить, разве нет?

Ну вот вы только что использовали выше в картинке торговую марку другого лица без разрешения правообладателя.

То, что вы описываете - это ваше понимание. Я был бы рад ссылкам на правовую базу всё таки. Особенно, если там iframe упоминается.

Это неудачная аналогия. Никто не заходил в чужой дом без разрешения. В чём концептуальная разница между заходом на сайт и отображением сайта в iframe? Только с юридической, а не этической точки зрения

А вы знаете? Давай с юридической точки зрения, что значит торговая марка и какие ограничения накладываются на использование сайта, который внутри содержит игру с зарегистрированной торговой маркой?

Ещё раз, разработчик разрешил просмотр его сайта. Он никак не ограничил его отображение в iframe.

И вы не ответили на мой первый вопрос, я повторю:

Если я захожу на ваш сайт, я тоже ворую ваши деньги?

А в целом, вы приводите неудачные аналогии)

Если вы раздаёте бесплатно воду, то никто не запретит кому то перепродавать эту воду.

Да, это будет неэтично, но это не является воровством.

Если я захожу на ваш сайт, я тоже ворую ваши деньги?

Ну и в примере нигде никто не присваивал чужой собственности, вроде бы.

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

Кажется, действительно, было не этично, но это всё таки это не воровство с юридической точки зрения.

Автор сам разрешил пользоваться его сайтом и не выставил никаких ограничений.

А почему API социальных сетей вынесено отдельным пунктом? Чем отличается от web api?

В России очень хорошо развиты компании работающие в ФинТех, соответственно, когда мы говорим об API, то традиционно подразумеваем микросервисные API, а особенно протоколы REST и SOAP.

Откуда такой вывод вдруг?

Отсутствие строгой спецификации может привести к разнообразию реализаций и сложностям в согласованности интерфейсов.

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

Так просто или сложно все таки? И почему вдруг REST делает необязательнымт знания о внутреннем устройстве? Кажется любой api (нормальный) как раз делает знания необязательными, т.к. предоставляет интерфейс

Сделайте мне бота, который будет по фамилии и городу предоставлять ник пользователей в телеграм

При этом метод называется search_relatives. Кажется в REST стиле было бы что то типа nicknames/search например. Непонятно при чем тут relatives вообще

Как вообще что то может "превысить в геометрической прогрессии"? :)

Ваша правда, не учёл, как именно работает ?.

Просто возникла идея, что когда то там могло быть model.GetDefaultSchema() с обработкой null внутри, пока не появились NRT :)

model?.GetDefaultSchema()

Кажется такое имело бы смысл, если бы метод расширения GetDefaultSchema (а это вроде extension метод), принимал бы на вход nullable тип и имел какую то ветку выполнения для случая, когда this равно null.

Тогда было бы логично всё)

Информация

В рейтинге
5 670-й
Откуда
Россия
Работает в
Зарегистрирован
Активность