Никогда не понимал смысла таких вопросов на собеседовании, если компания занимается недвижимостью для слепых жирафов, и человеку говорят "Нарисуйте домик", нормальный работник нарисует домик для слепого жирафа. А они хотят нанять человека, который соберет 20 митингов, где будет уточнять для слона нужен домик или для жирафа?
Также можно ответить на вопрос "почему integer, а не string": дело в том, что поля типа string подвержены грамматическим ошибкам и всё что они дают - это удобство чтения таких данных в одной конкретной таблице без использования SQL запросов с применением JOIN функций.
Не стоит недооценивать удобство чтения.
У int есть один недостаток, через n лет красивый int enum превратится в: enum StatusEnum: int { case New = 0; case Legacy = 1; case Done = 2; case Failed = 3; case Deleted = 4;
Обязателен ли файл startup.cs или нет? Да, startup.cs является обязательным, его можно специализировать любым модификатором доступа, например, public, private, internal
противоречит
Можем ли мы удалить startup.cs и объединить все в один класс с Program.cs?
Ответ: Да,
На самом деле, нам достаточно определить Configure и ConfigureServices. Например:
Потому что, это естественная потребность. Самые дорогие и восстребованные проститутки - это те, которые приятны в общении, могут поддержать разговор. Можно почитать, например, отзывы на их сайтах.
Самый пик мастерства у них, это когда клиент как-будто пришел к старой знакомой, они хорошо провели время и нет ощущения, что побывал у проститутки. И физический контакт в нем вообще не главное
Смысл этого предложения несколько кривой, наверное ты подразумевал «иметь одну ответственность».
Uncle Bob настаивает именно на этом определении: https://blog.cleancoder.com/uncle-bob/2014/05/08/SingleReponsibilityPrinciple.html
Если функция выполняет «А», то причина изменения может быть, то что бизнес требование «А» поменялось. Если есть другая бизнес задача «Б» , которая по совпадению имеет такой же код как и «А», то, согласно принципу они должны лежать в разных местах, и если требование к «А» (но не «Б») поменялись, то можно без проблем поменять код в одном месте
Ну понятно, в программировании вообще нет абсолютных правил, только гайдлайны.
Когда мы выносим в одну функцию код, который не связан логикой мы нарушаем Single Responsibility Principle: каждый класс должен иметь только одну причину для изменения. Все дальнейшие проблемы от этого
Когда читал статью думал, что это сарказм -- "вредные советы" для "эффективных" менеджеров. Прочитав комментарии, понял, что я единственный так подумал
У нас докер контейнеры пишут в свои лог файлы, затем дифф этих файлов отправляются newrelic утилитой на докер хосте, все работает нормально, по крайней мере, с нашей нагрузкой
Импорт логов из одной 3rd party в другую 3rd party, такого, да во фреймворке нет. То, что в гитхабе 5 звезд, может говорит, о том, что это не супер распространненая вещь?
Я не работал с fluentd, мы использовали kibana и newrelic, используем подход, похожий на dbones.github.io/2019/11/efk-with-serilog
Библиотеки в дотнете почти всегда есть нужные, но джава куда богаче конечно на выбор, а сами библиотеки обычно более заматеревшие.
Насчет выбора согласен, но это может быть как преимуществом, так и недостатком, из-за зоопарка всяких библиотек, могут быть проблемы. Насчет, того, что они более заматеревшие, не уверен
Никогда не понимал смысла таких вопросов на собеседовании, если компания занимается недвижимостью для слепых жирафов, и человеку говорят "Нарисуйте домик", нормальный работник нарисует домик для слепого жирафа.
А они хотят нанять человека, который соберет 20 митингов, где будет уточнять для слона нужен домик или для жирафа?
То есть надо покупать и электронную и аудиокнигу?
Я думаю, это проблемы переходного периода. В будущем уже будут ИИ-звезды, защищенные копирайтом, а фильмы с реальными актерами будут нишей хипстеров
Не стоит недооценивать удобство чтения.
У int есть один недостаток, через n лет красивый int enum превратится в:
enum StatusEnum: int{
case New = 0;
case Legacy = 1;
case Done = 2;
case Failed = 3;
case Deleted = 4;
case NewStatus = 376;case AnotherNewStatus = 378;}
Не понятно почему Visual studio и VsCode вместе, между ними столько же общего как у java с javascript
противоречит
На самом деле, нам достаточно определить Configure и ConfigureServices. Например:
Потому что, это естественная потребность. Самые дорогие и восстребованные проститутки - это те, которые приятны в общении, могут поддержать разговор. Можно почитать, например, отзывы на их сайтах.
Самый пик мастерства у них, это когда клиент как-будто пришел к старой знакомой, они хорошо провели время и нет ощущения, что побывал у проститутки. И физический контакт в нем вообще не главное
А что не так с мигрантами?
Uncle Bob настаивает именно на этом определении: https://blog.cleancoder.com/uncle-bob/2014/05/08/SingleReponsibilityPrinciple.html
Если функция выполняет «А», то причина изменения может быть, то что бизнес требование «А» поменялось. Если есть другая бизнес задача «Б» , которая по совпадению имеет такой же код как и «А», то, согласно принципу они должны лежать в разных местах, и если требование к «А» (но не «Б») поменялись, то можно без проблем поменять код в одном месте
https://blog.cleancoder.com/uncle-bob/2014/05/08/SingleReponsibilityPrinciple.html
Ну понятно, в программировании вообще нет абсолютных правил, только гайдлайны.
Когда мы выносим в одну функцию код, который не связан логикой мы нарушаем Single Responsibility Principle: каждый класс должен иметь только одну причину для изменения. Все дальнейшие проблемы от этого
Вот она причина, повторяется она по чистому совпадению. Если нельзя разбить на логические утилитнные функции, я всегда против переиспользования
Давайте посмотрим на автора вопроса. Он находится в Израиле, может позволить себе не работать 1.5 года, не имеет обязательств.
Такие стартовые условия мало у кого есть, и когда он добьется успеха, можно будет сказать: "Это все удача"
По закону больших чисел, такие "удачи" приходят к каждому, просто кто-то использует ее, а кто-то нет
А если автор письма устроится на работу, он также будет писать кому-нибудь из stackoverflow, с советом не попадаться на глаза?
Я думал как раз преимущество более старших работников в готовности брать на себя
отвественность.
Когда читал статью думал, что это сарказм -- "вредные советы" для "эффективных" менеджеров. Прочитав комментарии, понял, что я единственный так подумал
github.com/serilog/serilog-sinks-elasticsearch
Я не работал с fluentd, мы использовали kibana и newrelic, используем подход, похожий на dbones.github.io/2019/11/efk-with-serilog
Насчет выбора согласен, но это может быть как преимуществом, так и недостатком, из-за зоопарка всяких библиотек, могут быть проблемы. Насчет, того, что они более заматеревшие, не уверен