У меня очень похожий подход.
У меня в собеседовании обычно три фазы: я рассказываю про нас и проект (если кандидату это не интересно уже тут можно вежливо разойтись), потом спрашиваю про знание технологий, потом про опыт.
Про технологии я просто начинаю спрашивать о том, что кандидат обозначает как «знаю». Знает, что такое multithreading в .net — спрошу про способы реализации и проблемы разных подходов, потом ещё глубже можно копнуть, например про синхронизацию и способы борьбы с блокировками. А можно спросить, какие задачи решились многопоточностью.
Про опыт как раз спрашиваю про сложные и интересные задачи из личного опыта, что это было, как решалось, пригодилось ли в будущем.
Таким образом оцениваю и хард и софт скиллы, как человек думает, склонен ли докапываться до сути, сам решает проблемы или с гуглом/коллегами, знает ли он заказчиков/клиентов или старается их избегать…
Я правильно понимаю, что вся эта простыня сводится к тому, что сам парсинг всегда законен, т.к. подразумевает такой же доступ к данным, какой есть у обычного пользователя.
Проблемы будут если:
— есть эффект DoS
— используются «средства преодоления защиты»
— имеет место неправомерное использование полученной информации
Т.е. единственная потенциальная проблема именно парсинга — повышенная нагрузка на ресурс.
Ну… тогда за последние 20 лет ничего в этой области не изменилось…
ну подумаешь, треть слишком категоричны, часть тех, кто за, наверно, несколько наивны. Нормальное такое распределение.
Повторюсь (хотя для этой заметки уже поздно, наверно), лучше бы показали, как грамотно писать ОО-модель так, чтобы не возникало подобных «каверзностей».
Скажем так: если в вашей доменной модели нельзя наследовать пингвина от птицы — у вас что-то пошло не так :)
А в остальном — капитанская заметка, не претендующая на звание статьи…
Нет бы рассмотреть корректные варианты реализации, когда и ООП нормальное и мозг не ломается?
Если уж хочется по простому переписать, то вот вам вариант:
public sealed class Loop
{
public static void ForNext(int start, int end, int step, Action<int> action)
{
int ind = start;
while(step > 0 ? ind <= end : ind >= end)
{
action(ind);
ind += step;
}
}
}
class Program
{
static void Main(string[] args)
{
Console.WriteLine("begin up loop");
var s = "=>";
Loop.ForNext(1, 6, 2, (n) => Console.WriteLine(s+n));
Console.WriteLine("begin down loop");
s = "<=";
Loop.ForNext(5, -2, -2, (n) => Console.WriteLine(s+n));
Console.ReadLine();
}
}
Выведет:
begin up loop
=>1
=>3
=>5
begin down loop
<=5
<=3
<=1
<=-1
Вы наверняка слышали утверждения вроде: «Наши убеждения меняют реальность». Но так ли это?
Либо вы не понимаете этого утверждения, либо осознанно трактуете его слишком дословно.
Имхо, было бы сильно полезнее вместо многословно капитанской заметки рассказать, в чём суть означенного утверждения.
Суть проста, но отрывает путь в реальную реальность :).
Реальность, в которой мы живём, есть кривое отражение абсолютной действительности, и наши убеждения задают степень кривизны и даже конкретную форму искажений. Таким образом, меняя убеждения таки можно менять реальность.
А самая суть в том, что изменять убеждения можно (и надо) так, чтоб реальность менялась в нужную сторону. Проблема только в том, чтобы понять, куда именно надо менять, и как…
В абстрактном вопросе для собеседования «REST и SOAP: в каких ситуациях вы выберете один из этих подходов, а в каких другой?»
если вопрос был бы именно таким, я бы предпочёл рассуждения о связности систем, имеющихся ограничениях, сложностях реализации.
Например: soap «тяжелее» rest по объёму данных; требует сторонних библиотек, если клиент на js (без либы писать и разбирать запросы будет сложно); но, если сервер предоставляет wsdl, можно написать типизированного клиента; правда и для rest можно воспользоваться swagger и для просмотра api и для генерации клиента; а если вдруг и клиент и сервер — это модули нашей разработки, то логично было бы вынести описание апи в отдельную библиотеку, что уменьшит вероятность ошибок в реализации, и, при этом, если с обоих сторон js — проще делать rest, а если это бэк — то проще сделать soap.
При этом архитектурной разницы между этим типами api нет. Вы в статье пишете, что в одном из кейсов rest не подходит, но это выглядит как немотивированное требование к «чистоте» rest-api, но у этого требования очень низкий приоритет. А вот реализация идемпотентности никак не зависит от выбранного протокола.
Автор, я правильно понимаю, что выбор архитектуры взаимодействия вы делаете на основе внутренностей целевой системы? Никогда такого подхода не встречал…
Стандартный подход — оцениваем требования к синхронности, наличию ответов, скорости, нагрузке, многозвенности, гарантий доставки/обработки, параллельной обработке, безопасности. Оцениваем технологические ограничения (кто-то не умеет gRPC, иногда вообще только http и.т.д.), наличествующие готовые решения.
Исходя из этого выбираем наиболее подходящие решения, оцениваем стоимость разработки.
И на первом месте будет естественным образом архитектура взаимодействия и сценарии использования, а уж потом вырисуется REST/SOAP/WCF/gRPC/MQ/Sokets/Files/RPC/etc.
А у вас как-то получилось, что вы вытащили наружу кишки системы и выбираете наиболее удобный способ взаимодействия с ними.
Пользы от описания архитектур было бы значительно больше, если бы сначала разобрать, как будет строиться приложения и от этого выйти к полезным паттернам.
Второе, в описание паттернов у вас каша получилась, что сильно портит впечатление. То вы сетуете на ViewController там, где его нет. То вам не нравится описание паттерна на C#, хотя проект делается на нём же. Или у вас, вдруг, в C# появились Form, хотя в языке нет такого ключевого слова.
Тут дело не в параметрах, но близко. В последней строке при получении элемента из листа возвращается копия всей структуры, а сохранения нет (в отличии от предыдущей строки), поэтому значение в листе не изменится.
На мои комментарии там (в шпаргалке) вы не ответили, давайте тут продолжим :)
Передача по значению / указателю
Вы удивитесь, но все параметры, кроме out и ref, передаются по значению, т.е. копируются в стек. И именно тут ваша шпаргалка вводит неофитов в заблуждение.
Вот только для reference типа копируется ссылка, а value тип копируется целиком.
И из-за непонимания этих фактов получаются забавные баги:
Многие пытаются в методе изменить объект reference-типа просто присвоим переменной в методе новое значение.
и классика жанра — поменять поле value-типа и удивляться тому, что после вызова метода всё осталось как есть.
string — особенный тип
вот только вы упорно говорите, что string ведёт себя как value-тип, что совершенно не верно. Ну и про конкатенацию не то пишете. Тип и правда интересный и полезно знать его особенности, но про них вы не пишете.
Можно улучшать, но лучше в подобном стиле излагать другие стандарты и особенности.
Например про особое отношений компилятора к строкам и зачем появился StringBuilder.
да, кстати, стало не лучше.
вот эти оба пункта неверны:
из-за того, что строки immutable и при сравнении сравниваются их значения (стандартное поведение reference type сравнивать ссылки) строки по поведению похожи на value type
из-за immutable при склеивании длинных строк нужно использовать StringBuilder
Тип особенный, но вы совсем не то про него пишете!
Прежде чем делать дальнейшие изменения этого раздела, разберитесь, почему в мой пример работает именно так, как описано.
У меня в собеседовании обычно три фазы: я рассказываю про нас и проект (если кандидату это не интересно уже тут можно вежливо разойтись), потом спрашиваю про знание технологий, потом про опыт.
Про технологии я просто начинаю спрашивать о том, что кандидат обозначает как «знаю». Знает, что такое multithreading в .net — спрошу про способы реализации и проблемы разных подходов, потом ещё глубже можно копнуть, например про синхронизацию и способы борьбы с блокировками. А можно спросить, какие задачи решились многопоточностью.
Про опыт как раз спрашиваю про сложные и интересные задачи из личного опыта, что это было, как решалось, пригодилось ли в будущем.
Таким образом оцениваю и хард и софт скиллы, как человек думает, склонен ли докапываться до сути, сам решает проблемы или с гуглом/коллегами, знает ли он заказчиков/клиентов или старается их избегать…
В чём преимущества использования Serilog по сравнению с NLog?
Проблемы будут если:
— есть эффект DoS
— используются «средства преодоления защиты»
— имеет место неправомерное использование полученной информации
Т.е. единственная потенциальная проблема именно парсинга — повышенная нагрузка на ресурс.
Ну… тогда за последние 20 лет ничего в этой области не изменилось…
Повторюсь (хотя для этой заметки уже поздно, наверно), лучше бы показали, как грамотно писать ОО-модель так, чтобы не возникало подобных «каверзностей».
А в остальном — капитанская заметка, не претендующая на звание статьи…
Нет бы рассмотреть корректные варианты реализации, когда и ООП нормальное и мозг не ломается?
Выведет:
Имхо, было бы сильно полезнее вместо многословно капитанской заметки рассказать, в чём суть означенного утверждения.
Суть проста, но отрывает путь в реальную реальность :).
Реальность, в которой мы живём, есть кривое отражение абсолютной действительности, и наши убеждения задают степень кривизны и даже конкретную форму искажений. Таким образом, меняя убеждения таки можно менять реальность.
А самая суть в том, что изменять убеждения можно (и надо) так, чтоб реальность менялась в нужную сторону. Проблема только в том, чтобы понять, куда именно надо менять, и как…
Например: soap «тяжелее» rest по объёму данных; требует сторонних библиотек, если клиент на js (без либы писать и разбирать запросы будет сложно); но, если сервер предоставляет wsdl, можно написать типизированного клиента; правда и для rest можно воспользоваться swagger и для просмотра api и для генерации клиента; а если вдруг и клиент и сервер — это модули нашей разработки, то логично было бы вынести описание апи в отдельную библиотеку, что уменьшит вероятность ошибок в реализации, и, при этом, если с обоих сторон js — проще делать rest, а если это бэк — то проще сделать soap.
При этом архитектурной разницы между этим типами api нет. Вы в статье пишете, что в одном из кейсов rest не подходит, но это выглядит как немотивированное требование к «чистоте» rest-api, но у этого требования очень низкий приоритет. А вот реализация идемпотентности никак не зависит от выбранного протокола.
Стандартный подход — оцениваем требования к синхронности, наличию ответов, скорости, нагрузке, многозвенности, гарантий доставки/обработки, параллельной обработке, безопасности. Оцениваем технологические ограничения (кто-то не умеет gRPC, иногда вообще только http и.т.д.), наличествующие готовые решения.
Исходя из этого выбираем наиболее подходящие решения, оцениваем стоимость разработки.
И на первом месте будет естественным образом архитектура взаимодействия и сценарии использования, а уж потом вырисуется REST/SOAP/WCF/gRPC/MQ/Sokets/Files/RPC/etc.
А у вас как-то получилось, что вы вытащили наружу кишки системы и выбираете наиболее удобный способ взаимодействия с ними.
Второе, в описание паттернов у вас каша получилась, что сильно портит впечатление. То вы сетуете на ViewController там, где его нет. То вам не нравится описание паттерна на C#, хотя проект делается на нём же. Или у вас, вдруг, в C# появились Form, хотя в языке нет такого ключевого слова.
Вы удивитесь, но все параметры, кроме out и ref, передаются по значению, т.е. копируются в стек. И именно тут ваша шпаргалка вводит неофитов в заблуждение.
Вот только для reference типа копируется ссылка, а value тип копируется целиком.
И из-за непонимания этих фактов получаются забавные баги:
вот только вы упорно говорите, что string ведёт себя как value-тип, что совершенно не верно. Ну и про конкатенацию не то пишете. Тип и правда интересный и полезно знать его особенности, но про них вы не пишете.
Можно улучшать, но лучше в подобном стиле излагать другие стандарты и особенности.
Например про особое отношений компилятора к строкам и зачем появился StringBuilder.
вот эти оба пункта неверны:
Тип особенный, но вы совсем не то про него пишете!
Прежде чем делать дальнейшие изменения этого раздела, разберитесь, почему в мой пример работает именно так, как описано.