Причем здесь восприятие? Статья написана на английском языке. У слов есть конкретное значение, которое они несут в себе. То, что вам не понравился перевод названия на русский язык - ваши проблемы. А демагогию разводите вы, ибо вам непонятно что означает то или иное слово и вам "это кажется призывом".
И? Как это отменяет мой тезис о том, что отсутствие софта под Linux следствие низкого спроса на этот софт под Linux, который является следствием отсутствия софта под Linux и т.д.?
Не, я не принуждаю никого переходить. Windows уже фактически монополист в сфере ОС для ПК. Осталось подождать когда она начнет еще более нагло себя вести с пользователями, а далее лишь наблюдать их реакцию :)
Конечно же, документ поплывёт, если каждый будет применять стили из своего локального шаблона, а не стили документа.
Ну тогда вопрос в том, почему у меня на двух ПК с одинаковой версией офиса (на одном сразу после установки офиса) проблем не было, не было и проблем с такой же версией офиса на ПК одногруппника? Если проблема именно в стилях, то тогда и в этих случаях все должно было плыть...
По факту - проблема была массовой именно из-за разных версий офиса, решалась либо демонстрацией работы с собственного ноутбука, либо установкой такой же версии офиса -_-
Насколько помню, был ГОСТ, требования к шрифтам и конкретное требование делать все в Word'е, в том числе чтобы руководители могли спокойно ознакомляться с "творчеством" студентов
Вроде вы не очень понимаете значения фразы "вам следует поступить так же" - это совет, а не приказ, который обязывает сделать что-то.
"should" - совет, рекомендация, пусть и настоятельная, но не обязательная. Советы и рекомендации не подразумевают, что человек должен полностью в специфику другого человека залезть.
Если вам терапевт скажет что "следует обратиться к окулисту с этим вопросом", то это всего лишь рекомендация, но не более. Вы вольны ее не выполнять. Другое дело когда врач говорит что "ты должен неукоснительно измерять уровень сахара три раза в день" - это уже именно императив.
Самая главная проблема - отсутствие аналога какого-то софта.
Мы как-нибудь сами решим что является проблемой, а что нет. Исходя из своих задач и потребностей.
Любой адекватный человек, когда хочет перейти на что-то от другого производителя - сядет и будет рыть информацию по доступности софта, функций, удобств и/или их аналогов. И будет самостоятельно решать нужно оно ему или нет. Осуждать других за то, что не указали что именно ваш софт не работает, руль в ваше пузо упирается, бумага свободным концом не туда смотрит, ваш аллерген присутствует - глупо и бессмысленно. Автор описывает субъективный опыт и призывает других попробовать. Не вижу в этом никаких проблем.
Ну так и пишите письма разработчикам ПО чтобы они начали поддерживать Linux дистрибутивы.
вы можете сделать это электролобзиком. Но циркуляркой вы это сделаете быстрее, проще и ровнее.
Только это разные инструменты - первый предназначен для криволинейного пиления, а второй для прямолинейного. Для большинства людей переход на Linux скорее связан с тем, что у них вместо линейки инструмента от одного производителя появится несколько линеек от разных производителей и это "неудобно".
Когда диплом писал в Word 2016 отправлял его на проверку руководителю и у него в Word 2007 все плыло :) В том числе указывал что убирал какие-то пустые страницы, переносы, правил отступы и т.п. После таких исправлений - уже у меня документ плыл. Единственным решением было использование PDF - составлялся отдельный список где и что нужно поправить и правки вносил уже я, отправляя на согласование новую версию документа.
Ну автор статьи описывает субъективный опыт перехода на другую ОС. Почему у него должны быть какие-то размышления на тему "недоступности какого-то удобного ПО", если он сам с этим не сталкивался? Ну вот я использую Markor для написания заметок на телефоне. Должен ли человек, который перешел на IOS писать о недоступности этого ПО? Нет. Должен ли он писать о недоступности гибкой настройки фоновой работы приложений? Нет. И т.д. Аналогично и о недоступности каких-то приложений с IOS на Android писать нет никакого смысла.
Running HeidiSQL on Wine is currently quite unstable.The native Linux versionmay be an alternative for you if you get issues through Wine.
Насколько понимаю, нет только портативной версии под Linux. Ну и справедливости ради, версия под Linux чуть более полугода назад появилась.
Но вообще, довольно странно относить к недостаткам ОС отсутствие какого-то ПО, которое разрабатывается сторонней компанией, т.к. это сторонние разработчики не хотят распространять свое ПО на эту ОС. И тут как бы стандартный замкнутый цикл: 1) Чтобы сделать ПО - нужны пользователи 2) Что бы были пользователи - нужно ПО 3) go to 1
Звучит как, "мне под 60 и я не буду учить что то новое. Нас и так не плохо кормят".
Скорее так: "Есть библиотека на другом языке, использование которой приводит к критическим ошибкам из-за кода самой библиотеки - кто, когда и как исправит ее?"
Т.е. вам либо нужно изучать другой язык, что бы самостоятельно внести нужные изменения, либо искать человека, который уже знает этот язык и сможет внести необходимые изменения, кооперироваться, тестировать и т.д. А если что-то сломалось в другой части проекта из-за этого изменения - начинать сначала? Если же все написано на одном языке - можно спокойно самостоятельно внести необходимые изменения, протестировать и т.д. И если что-то сломалось в другой части проекта - другой разработчик сможет самостоятельно внести изменения. По скорости и удобству, последний вариант - выигрывает.
Изучение другого языка требует времени, при этом никто не даст гарантий того, что потраченный год (условно) позволит писать хороший код на новом языке. Но есть и дополнительные проблемы - отсутствие свободного времени (все же взрослые люди, семья, дети, банальная усталость), потеря скорости обучения с возрастом и т.д. Т.е. для перехода старых разработчиков на новый стек потребуется неизвестное кол-во времени и это без какой-либо гарантии результата.
Вообще есть три вопроса, на которые нужно ответить перед написанием документации:
Для кого пишется документ?
Если документ пишется для себя, то формат, используемые фичи и т.п. вещи - не имеют значения. Делайте так, как вам будет удобно потом воспринимать текст. Если пишите для команды, пользователей, руководства и т.д., то следует использовать те инструменты, с которыми они знакомы и которые им будет удобно воспринимать. Я, например, периодически использую plantuml в markdown файлах, но для многих без "итоговых картинок" - это будет не читаемо.
Где будут читать документ наиболее часто?
Удаленный терминал с низким разрешением экрана - строгие ограничения под него. 128к монитор - ограничения под него. Сайт - ограничения под сайт. И т.д.
В каком формате будут читать документ?
Сам исходный файл - тогда делаем его максимально понятным для чтения, таблицы только небольшие, однострочные и т.д. и т.п. Сгенерированный документ PDF или предпросмотр - хоть смайлик розового слона верхом на единороге используй для выделения заголовков вместо #, главное чтоб в итоговом виде было читабельно.
Как видно, восприятие таблицы в PDF значительно ухудшается: три страницы против одной.
О нет, используя таблицы в документации вы провоцируете производить больше виртуальной бумаги и тем самым лишаете домика множество индексов БД!
А вообще это отличный пример того, как автор нарушает собственный же совет (не перегружать ячейки содержимым) для доказательства своей точки зрения :)
Скрытый текст
Конвертировал через VSCode Markdown-PDF со стандартными настройками
Поиграться со шрифтами убрать колонтитулы и глядишь все уместится на один лист. Если выкинуть допустимые значения NGINX_GZIP_PROXIED в отдельную таблицу и поставить на нее ссылку, то будет еще лучше. Цветовая схема не очень, да, правится в конфиге.
К сожалению, я не нашел явных преимуществ использования таблиц в данном контексте
У меня RG35XX обычная с Garlic OS. Характеристики похуже (quad-core ARM Cortex-A9, 256мб ОЗУ DDR3 и т.д.). Тянет все до PS1 без особых нареканий. У модели RG35XX H добавлены эмуляторы PSP/Dreamcast/N64, возможно NDS (точно не помню), и стоит Allwinner H700 (в целом, характеристики идентичны новой консоли). Насколько знаю, проблемы с играми на добавленных эмуляторах встречаются только на "тяжелых" играх. Но там хотя бы стики имеются, а тут этого нет.
Использовать "Теги", которые есть в Outlook - да не, бред. Уведомления о доставке и прочтении - так же бред.
Что посоветуете?
Для начала, в случае игнора на первое письмо - использовать фишки почты, о которых написал выше. И использовать правильную нумерацию, ибо у вас один пункт пропущен:
Конкретика. В письме не должно быть воды. Вопросы должны быть простыми, понятными, без додумываний, двойных смыслов и т. п. «Подскажите по срокам» — это непонятно, т.к. можно подсказать «адекватные ли сроки», «уложимся ли мы в них», «будет ли готово день в день или раньше» и т. д. Конкретный вопрос — залог успеха. Простой конкретизированный вопрос - проще дать ответ сразу. Сложный вопрос с неопределенным смыслом - надо обдумать и потом как-нибудь отвечу.
По остальным пунктам уже критика:
Да
Бред. Почему именно 2 минуты? У меня может не быть сейчас 2х минут на болтовню с кем-либо. У меня может вообще не быть времени на разговоры с этими "эээээээм, амммммммм, хммм". Так же полностью нарушает первый пункт - на тему чего разговаривать то собралась? Видео с котиками обсудить? Может разговор затянется, т.к. к вашим вопросам необходимо подготовиться, подняв кипу документов или задач. В 99% случаях подобные запросы на "беседу" будут игнорироваться. Кроме того, устный ответ - это ответ без явного подтверждения, так что все равно будете повторно запрашивать ответ в письме, т.е. придется делать двойную работу и тратить заметно больше времени.
Это добавляет плюсов в пользу нежелания с вами общаться. Стандартные способы выделения - полужирный, курсив и подчеркивание - ничем не хуже, при этом вызывают меньше гнева и никак вообще не страдают от настроек почтового клиента или ОС.
Первый раз просто пишете письмо человеку, от которого нужен ответ. Второй раз пишете такое же письмо с тегами "важно, срочно и т.д.". В третий раз уже добавляете руководителей. Если сразу добавляете руководителя - идете нафиг, еще и руководитель подкинет пару крепких слов для ускорения движения в заданном направлении. Исключения - прям очень срочные письма, но такие встречаются крайне редко.
Есть ощущение, что вы не понимаете куда вообще надо писать и пишете случайному разработчику команды, которая ответственна за задачу. В первую очередь необходимо найти к кому непосредственно обращаться.
Дефолт
Никак не влияет.
Рабочее письмо - это не курсовая, нир или вкр, тут не нужно воды вообще. Максимально кратко и понятно описали что вам нужно - получили ответ. Налили воды - ваше письмо будет в числе последних, на которое будут тратить свое время.
Странно, я всегда считал это адекватным поведением - когда ты запрещаешь любую фоновую активность приложению и оно реально не работает в фоне, если не свернуто. А если свернул и зашел в список последних приложений, после нажатия кнопки закрытия - они все закрываются и перестают работать. Сейчас на Realme, несмотря на все запреты, после перезагрузки устройства - все приложения начинают работать в фоне и присылать уведомления. Приходится заходить в список приложений и принудительно останавливать их. Аналогично и после использования какого-либо и закрытия всех последних - они все еще работают в фоне и шлют уведомления до прожатия "force stop". Очень раздражает.
В опросе мы просили указать ежемесячный доход в той валюте, в какой получаете зарплату, после вычета налогов и с учётом всех премий и надбавок.
Какой-то странный вариант. Премию могут не выплатить, т.к. не были достигнуты цели и т.д. Соответственно доход сократится. Если рассматривается "теоретический" доход, то он не соответствует реальности. Да и размеры премий у людей очень уж разный.
Как учитываются бонусы от компании - спортзал, ДМС, оплата связи, оборудование и т.п.?
и рассчитали медианные значения по нужным срезам
Как был произведен расчет с разбивкой по территориальным признакам? Если з/п в ₽, то это Россия или другие страны? А если проживаешь в Тайланде? Если з/п в $, проживаешь в Нигерии, работаешь удаленно в компании из РФ, то в куда относится зарплата?
Тэг на сервисе не должен говорить, как он это делает (file/rabbit/postgres), а должен говорить, какой бизнес-сценарий работает.
Согласен. В таком случае мы реализуем любую логику для конкретной ответственности (контроллера) независимо от других ответственностей. Так же это позволяет использовать внутри конкретных методов дополнительные зависимости для тех же логов.
Это отличное решение, на самом деле. Я пытался это объяснить, но, возможно, некорректно это сделал.
Но будем честны — это не решает проблему. Проще сразу поставить в зависимости конкретные типы.
Почему не решает? Потому что нужно будет один раз отредактировать нужные контроллеры?
Поставив конкретные типы вы обрекаете себя на необходимость изменять эти типы, если для какого-то сервиса вдруг понадобится подменить провайдер логирования, например для тестов. В случае именованной регистрации сервисов - достаточно будет подменить реализацию только в Startup.cs.
А именованные зависимости ещё и создают видимость какой-то правильности, хотя по существу являются нарушением инверсии зависимостей и требуют точно такой же конкретики, только каким-то очень извилистым образом.
Почему? Под именем "file" может скрываться создание файла с описанием ошибки и отправки его на почту разработчику, а может скрываться реализация записи данных в стандартный журнал ОС или что-то еще.
Да, вы зависите от конкретного именованного сервиса, но при этом не знаете какая реализация скрыта за этим именем, т.е. вы все еще зависите от абстракции (чуть более конкретной, но все еще абстракции), что и является определением инверсии зависимостей.
SOLID - это рекомендации по разработке ПО, а не конкретные требования. Иначе можем дойти до того, что нужны разные DTO и контроллеры для каждого действия CRUD над моделью данных из-за принципа единственной ответственности.
когда кто-то запрашивает зависимость, то он может предоставить поставщику критерий, в соответствии с которым тот может резолвить зависимости для него.
передав что именно запрашивается и кто именно запрашивает.
Ну т.е. конкретному поставщику зависимостей нужно будет знать о существовании всех контроллеров и на основе наименования/содержания/типа определять какой именно провайдер логирования нужен. В итоге, мы получим необходимость изменять +- тот же объем кода, просто в одном конкретном файле, а не в разных, при его добавлении в систему. В дальнейшем нам будет недостаточно сконфигурировать сервис в конструкторе, т.к. необходимо будет его добавить в поставщика зависимостей. А самый главный вопрос: какая именно реализация будет подставлена в контроллер, если мы забудем добавить его в список поставщика зависимостей? Как-то сложно, нет?
Да и именно этот вариант уже нарушает инверсию зависимостей, т.к. "модули должны зависеть от абстракций", а в вашем примере поставщик зависит от конкретного типа контроллера.
предоставить поставщику критерий, в соответствии с которым тот может резолвить зависимости для него.
Так вы и так предоставляете критерий при именованных зависимостях - имя.
Причем здесь восприятие? Статья написана на английском языке. У слов есть конкретное значение, которое они несут в себе. То, что вам не понравился перевод названия на русский язык - ваши проблемы.
А демагогию разводите вы, ибо вам непонятно что означает то или иное слово и вам "это кажется призывом".
И? Как это отменяет мой тезис о том, что отсутствие софта под Linux следствие низкого спроса на этот софт под Linux, который является следствием отсутствия софта под Linux и т.д.?
Не, я не принуждаю никого переходить. Windows уже фактически монополист в сфере ОС для ПК.
Осталось подождать когда она начнет еще более нагло себя вести с пользователями, а далее лишь наблюдать их реакцию :)
Ну тогда вопрос в том, почему у меня на двух ПК с одинаковой версией офиса (на одном сразу после установки офиса) проблем не было, не было и проблем с такой же версией офиса на ПК одногруппника? Если проблема именно в стилях, то тогда и в этих случаях все должно было плыть...
По факту - проблема была массовой именно из-за разных версий офиса, решалась либо демонстрацией работы с собственного ноутбука, либо установкой такой же версии офиса -_-
Насколько помню, был ГОСТ, требования к шрифтам и конкретное требование делать все в Word'е, в том числе чтобы руководители могли спокойно ознакомляться с "творчеством" студентов
Вроде вы не очень понимаете значения фразы "вам следует поступить так же" - это совет, а не приказ, который обязывает сделать что-то.
"should" - совет, рекомендация, пусть и настоятельная, но не обязательная. Советы и рекомендации не подразумевают, что человек должен полностью в специфику другого человека залезть.
Если вам терапевт скажет что "следует обратиться к окулисту с этим вопросом", то это всего лишь рекомендация, но не более. Вы вольны ее не выполнять.
Другое дело когда врач говорит что "ты должен неукоснительно измерять уровень сахара три раза в день" - это уже именно императив.
Так может тогда не надо в комментариях писать
Мы как-нибудь сами решим что является проблемой, а что нет. Исходя из своих задач и потребностей.
Любой адекватный человек, когда хочет перейти на что-то от другого производителя - сядет и будет рыть информацию по доступности софта, функций, удобств и/или их аналогов. И будет самостоятельно решать нужно оно ему или нет. Осуждать других за то, что не указали что именно ваш софт не работает, руль в ваше пузо упирается, бумага свободным концом не туда смотрит, ваш аллерген присутствует - глупо и бессмысленно. Автор описывает субъективный опыт и призывает других попробовать. Не вижу в этом никаких проблем.
Ну так и пишите письма разработчикам ПО чтобы они начали поддерживать Linux дистрибутивы.
Только это разные инструменты - первый предназначен для криволинейного пиления, а второй для прямолинейного.
Для большинства людей переход на Linux скорее связан с тем, что у них вместо линейки инструмента от одного производителя появится несколько линеек от разных производителей и это "неудобно".
Когда диплом писал в Word 2016 отправлял его на проверку руководителю и у него в Word 2007 все плыло :) В том числе указывал что убирал какие-то пустые страницы, переносы, правил отступы и т.п. После таких исправлений - уже у меня документ плыл.
Единственным решением было использование PDF - составлялся отдельный список где и что нужно поправить и правки вносил уже я, отправляя на согласование новую версию документа.
Ну автор статьи описывает субъективный опыт перехода на другую ОС. Почему у него должны быть какие-то размышления на тему "недоступности какого-то удобного ПО", если он сам с этим не сталкивался?
Ну вот я использую Markor для написания заметок на телефоне. Должен ли человек, который перешел на IOS писать о недоступности этого ПО? Нет. Должен ли он писать о недоступности гибкой настройки фоновой работы приложений? Нет. И т.д. Аналогично и о недоступности каких-то приложений с IOS на Android писать нет никакого смысла.
Help говорит обратное:
Насколько понимаю, нет только портативной версии под Linux. Ну и справедливости ради, версия под Linux чуть более полугода назад появилась.
Но вообще, довольно странно относить к недостаткам ОС отсутствие какого-то ПО, которое разрабатывается сторонней компанией, т.к. это сторонние разработчики не хотят распространять свое ПО на эту ОС. И тут как бы стандартный замкнутый цикл:
1) Чтобы сделать ПО - нужны пользователи
2) Что бы были пользователи - нужно ПО
3) go to 1
Ну как бы есть. И на сайте есть.
Не знал что что-то подобное есть на Pascal. Будет что изучить на досуге :)
Пробовали Markor?
Скорее так: "Есть библиотека на другом языке, использование которой приводит к критическим ошибкам из-за кода самой библиотеки - кто, когда и как исправит ее?"
Т.е. вам либо нужно изучать другой язык, что бы самостоятельно внести нужные изменения, либо искать человека, который уже знает этот язык и сможет внести необходимые изменения, кооперироваться, тестировать и т.д. А если что-то сломалось в другой части проекта из-за этого изменения - начинать сначала?
Если же все написано на одном языке - можно спокойно самостоятельно внести необходимые изменения, протестировать и т.д. И если что-то сломалось в другой части проекта - другой разработчик сможет самостоятельно внести изменения.
По скорости и удобству, последний вариант - выигрывает.
Изучение другого языка требует времени, при этом никто не даст гарантий того, что потраченный год (условно) позволит писать хороший код на новом языке. Но есть и дополнительные проблемы - отсутствие свободного времени (все же взрослые люди, семья, дети, банальная усталость), потеря скорости обучения с возрастом и т.д. Т.е. для перехода старых разработчиков на новый стек потребуется неизвестное кол-во времени и это без какой-либо гарантии результата.
Вообще есть три вопроса, на которые нужно ответить перед написанием документации:
Для кого пишется документ?
Если документ пишется для себя, то формат, используемые фичи и т.п. вещи - не имеют значения. Делайте так, как вам будет удобно потом воспринимать текст.
Если пишите для команды, пользователей, руководства и т.д., то следует использовать те инструменты, с которыми они знакомы и которые им будет удобно воспринимать.
Я, например, периодически использую plantuml в markdown файлах, но для многих без "итоговых картинок" - это будет не читаемо.
Где будут читать документ наиболее часто?
Удаленный терминал с низким разрешением экрана - строгие ограничения под него. 128к монитор - ограничения под него. Сайт - ограничения под сайт. И т.д.
В каком формате будут читать документ?
Сам исходный файл - тогда делаем его максимально понятным для чтения, таблицы только небольшие, однострочные и т.д. и т.п.
Сгенерированный документ PDF или предпросмотр - хоть смайлик розового слона верхом на единороге используй для выделения заголовков вместо #, главное чтоб в итоговом виде было читабельно.
О нет, используя таблицы в документации вы провоцируете производить больше виртуальной бумаги и тем самым лишаете домика множество индексов БД!
А вообще это отличный пример того, как автор нарушает собственный же совет (не перегружать ячейки содержимым) для доказательства своей точки зрения :)
Скрытый текст
Поиграться со шрифтами убрать колонтитулы и глядишь все уместится на один лист.
Если выкинуть допустимые значения
NGINX_GZIP_PROXIEDв отдельную таблицу и поставить на нее ссылку, то будет еще лучше.Цветовая схема не очень, да, правится в конфиге.
Оно ровно такое же, как и везде - наглядность.
У меня RG35XX обычная с Garlic OS. Характеристики похуже (quad-core ARM Cortex-A9, 256мб ОЗУ DDR3 и т.д.). Тянет все до PS1 без особых нареканий.
У модели RG35XX H добавлены эмуляторы PSP/Dreamcast/N64, возможно NDS (точно не помню), и стоит Allwinner H700 (в целом, характеристики идентичны новой консоли). Насколько знаю, проблемы с играми на добавленных эмуляторах встречаются только на "тяжелых" играх. Но там хотя бы стики имеются, а тут этого нет.
Использовать "Теги", которые есть в Outlook - да не, бред. Уведомления о доставке и прочтении - так же бред.
Для начала, в случае игнора на первое письмо - использовать фишки почты, о которых написал выше. И использовать правильную нумерацию, ибо у вас один пункт пропущен:
Конкретика. В письме не должно быть воды. Вопросы должны быть простыми, понятными, без додумываний, двойных смыслов и т. п. «Подскажите по срокам» — это непонятно, т.к. можно подсказать «адекватные ли сроки», «уложимся ли мы в них», «будет ли готово день в день или раньше» и т. д. Конкретный вопрос — залог успеха. Простой конкретизированный вопрос - проще дать ответ сразу. Сложный вопрос с неопределенным смыслом - надо обдумать и потом как-нибудь отвечу.
По остальным пунктам уже критика:
Да
Бред. Почему именно 2 минуты? У меня может не быть сейчас 2х минут на болтовню с кем-либо. У меня может вообще не быть времени на разговоры с этими "эээээээм, амммммммм, хммм". Так же полностью нарушает первый пункт - на тему чего разговаривать то собралась? Видео с котиками обсудить? Может разговор затянется, т.к. к вашим вопросам необходимо подготовиться, подняв кипу документов или задач. В 99% случаях подобные запросы на "беседу" будут игнорироваться. Кроме того, устный ответ - это ответ без явного подтверждения, так что все равно будете повторно запрашивать ответ в письме, т.е. придется делать двойную работу и тратить заметно больше времени.
Это добавляет плюсов в пользу нежелания с вами общаться. Стандартные способы выделения - полужирный, курсив и подчеркивание - ничем не хуже, при этом вызывают меньше гнева и никак вообще не страдают от настроек почтового клиента или ОС.
Первый раз просто пишете письмо человеку, от которого нужен ответ. Второй раз пишете такое же письмо с тегами "важно, срочно и т.д.". В третий раз уже добавляете руководителей. Если сразу добавляете руководителя - идете нафиг, еще и руководитель подкинет пару крепких слов для ускорения движения в заданном направлении. Исключения - прям очень срочные письма, но такие встречаются крайне редко.
Есть ощущение, что вы не понимаете куда вообще надо писать и пишете случайному разработчику команды, которая ответственна за задачу. В первую очередь необходимо найти к кому непосредственно обращаться.
Дефолт
Никак не влияет.
Рабочее письмо - это не курсовая, нир или вкр, тут не нужно воды вообще. Максимально кратко и понятно описали что вам нужно - получили ответ. Налили воды - ваше письмо будет в числе последних, на которое будут тратить свое время.
Странно, я всегда считал это адекватным поведением - когда ты запрещаешь любую фоновую активность приложению и оно реально не работает в фоне, если не свернуто. А если свернул и зашел в список последних приложений, после нажатия кнопки закрытия - они все закрываются и перестают работать.
Сейчас на Realme, несмотря на все запреты, после перезагрузки устройства - все приложения начинают работать в фоне и присылать уведомления. Приходится заходить в список приложений и принудительно останавливать их. Аналогично и после использования какого-либо и закрытия всех последних - они все еще работают в фоне и шлют уведомления до прожатия "force stop". Очень раздражает.
Какой-то странный вариант. Премию могут не выплатить, т.к. не были достигнуты цели и т.д. Соответственно доход сократится. Если рассматривается "теоретический" доход, то он не соответствует реальности. Да и размеры премий у людей очень уж разный.
Как учитываются бонусы от компании - спортзал, ДМС, оплата связи, оборудование и т.п.?
Как был произведен расчет с разбивкой по территориальным признакам? Если з/п в ₽, то это Россия или другие страны? А если проживаешь в Тайланде? Если з/п в $, проживаешь в Нигерии, работаешь удаленно в компании из РФ, то в куда относится зарплата?
Согласен. В таком случае мы реализуем любую логику для конкретной ответственности (контроллера) независимо от других ответственностей. Так же это позволяет использовать внутри конкретных методов дополнительные зависимости для тех же логов.
Это отличное решение, на самом деле. Я пытался это объяснить, но, возможно, некорректно это сделал.
Почему не решает? Потому что нужно будет один раз отредактировать нужные контроллеры?
Поставив конкретные типы вы обрекаете себя на необходимость изменять эти типы, если для какого-то сервиса вдруг понадобится подменить провайдер логирования, например для тестов. В случае именованной регистрации сервисов - достаточно будет подменить реализацию только в
Startup.cs.Почему? Под именем
"file"может скрываться создание файла с описанием ошибки и отправки его на почту разработчику, а может скрываться реализация записи данных в стандартный журнал ОС или что-то еще.Да, вы зависите от конкретного именованного сервиса, но при этом не знаете какая реализация скрыта за этим именем, т.е. вы все еще зависите от абстракции (чуть более конкретной, но все еще абстракции), что и является определением инверсии зависимостей.
SOLID - это рекомендации по разработке ПО, а не конкретные требования. Иначе можем дойти до того, что нужны разные DTO и контроллеры для каждого действия CRUD над моделью данных из-за принципа единственной ответственности.
Ну т.е. конкретному поставщику зависимостей нужно будет знать о существовании всех контроллеров и на основе наименования/содержания/типа определять какой именно провайдер логирования нужен. В итоге, мы получим необходимость изменять +- тот же объем кода, просто в одном конкретном файле, а не в разных, при его добавлении в систему. В дальнейшем нам будет недостаточно сконфигурировать сервис в конструкторе, т.к. необходимо будет его добавить в поставщика зависимостей. А самый главный вопрос: какая именно реализация будет подставлена в контроллер, если мы забудем добавить его в список поставщика зависимостей? Как-то сложно, нет?
Да и именно этот вариант уже нарушает инверсию зависимостей, т.к. "модули должны зависеть от абстракций", а в вашем примере поставщик зависит от конкретного типа контроллера.
Так вы и так предоставляете критерий при именованных зависимостях - имя.