А в каком проекте должен тогда находиться класс RegisterByEmail?
Обычно, Requests & Responses лежат где-то в отдельном проекте контрактов, а сама реализация в виде Handler лежит уже там где нужно. Как поступать в таком случае?
20-30 минут для 100 (или всё-таки 50?) миллионов документов это отличный результат.
По поводу префиксного поиска, тот же самый ElasticSearch это прекрасно умеет. Но с другой стороны это инфраструктурная зависимость, возможно есть смысл рассмотреть какой-нибудь LuceneNet?
Что-то очень маленькая производительность получилась «Тариф службы приложений B1 едва ли справляется с нагрузкой в 1 RPS.», как так то?
Осталось непонятным где именно проседает производительность, что это за «алгоритм соответствия имен, который отбирает очень много ресурсов»? Как вообще выглядит само приложение изнутри?
Отличная статья, рассматривались ли варианты вроде NetFabric.Hyperlinq или StructLinq, что-бы максимально сохранить простоту LINQ и не переписывать всё на циклы?
Вот ведь ответ: - 2 + 2. А если минус перед скобками, то это школьная арифметика, гуглить по словам: правило раскрытия скобок, перед которыми стоит знак минус
Что значит в чем смысл? Мы никогда не знаем, что придет нам на вход.
А что ж не указали что алгоритм перевода из инфиксной в постфиксную запись называется Алгоритм сортировочной станции?
Нам прямо предписывается использовать для обозначения унарного минуса любой свой придуманный символ. Давайте договоримся, что это будет тильда ~.
Унарный плюс не нужен, его можно просто найти и убрать, а унарный минус можно найти, убрать, и провести замену соответствующих последующих плюсов и минусов на противоположные знаки.
Но это проблемы не Синглтона, это проблемы архитектуры. Да и как он её тогда маскирует, если из статьи, на искусственных примерах, призванных подчеркнуть что этот паттерн зло, получается: «используется Синглтон — у тебя плохая архитектура»?
Нарушает принцип единственной ответственности класса.
Здесь абсолютно непонятно почему и ни слова об этом в статье не сказано.
Создает проблемы контроля многопоточности.
Это тоже никак не выводимо из текста статьи.
Вывод — надо уметь пользоваться инструментами и не делать из них карго-культа.
Неимоверно интересно было-бы увидеть решения этих задач конкретно от разработчиков компании.
Уверен, мы бы увидели много замечательного и узнали бы много нового!
Лучшим решением договорились считать такое, на понимание которого ревьювер тратит меньше всего времени (после прохождения всех остальных критериев).
Отличное решение, кстати могу дать ещё бесплатный совет как сократить количество заявок — выбросить половину, потому-что «а зачем нам нужны неудачники» (С)
Заманивали возможностью попасть на стажировку. Получить рабочий опыт в крупной компании, прокачаться в промышленной разработке и, возможно, после этого остаться на работу.
Скажем честно, человек который способен написать вон то мегатестовое задание качественно и в сжатые сроки — он и без вашей стажировки обойдётся.
Почитал новые тестовые, вот это конечно полный финиш:
И ещё, представляю какой бы крик поднялся, если бы стажёр подсунул бы вам решение, где возвращает кортежи из публичных методов, как будто так и надо. Почему же вы сами так пишете?
Обычно, Requests & Responses лежат где-то в отдельном проекте контрактов, а сама реализация в виде Handler лежит уже там где нужно. Как поступать в таком случае?
По поводу префиксного поиска, тот же самый ElasticSearch это прекрасно умеет. Но с другой стороны это инфраструктурная зависимость, возможно есть смысл рассмотреть какой-нибудь LuceneNet?
Осталось непонятным где именно проседает производительность, что это за «алгоритм соответствия имен, который отбирает очень много ресурсов»? Как вообще выглядит само приложение изнутри?
--2, то что будет в итоге?Вот ведь ответ:
- 2 + 2. А если минус перед скобками, то это школьная арифметика, гуглить по словам: правило раскрытия скобок, перед которыми стоит знак минусДля такого входные данные и нужно валидировать.
-2 - -2? Предполагаю что в итоге будет- 2 + 2.Кстати вариант про добавление эфемерного ноля, который тут упоминали в комментариях, тоже интересный, меньше мороки.
Унарный плюс не нужен, его можно просто найти и убрать, а унарный минус можно найти, убрать, и провести замену соответствующих последующих плюсов и минусов на противоположные знаки.
Но это проблемы не Синглтона, это проблемы архитектуры. Да и как он её тогда маскирует, если из статьи, на искусственных примерах, призванных подчеркнуть что этот паттерн зло, получается: «используется Синглтон — у тебя плохая архитектура»?
Здесь абсолютно непонятно почему и ни слова об этом в статье не сказано.
Это тоже никак не выводимо из текста статьи.
Вывод — надо уметь пользоваться инструментами и не делать из них карго-культа.
Уверен, мы бы увидели много замечательного и узнали бы много нового!
Отличное решение, кстати могу дать ещё бесплатный совет как сократить количество заявок — выбросить половину, потому-что «а зачем нам нужны неудачники» (С)
Скажем честно, человек который способен написать вон то мегатестовое задание качественно и в сжатые сроки — он и без вашей стажировки обойдётся.
Почитал новые тестовые, вот это конечно полный финиш:
И ещё, представляю какой бы крик поднялся, если бы стажёр подсунул бы вам решение, где возвращает кортежи из публичных методов, как будто так и надо. Почему же вы сами так пишете?
Вот что-бы например принципиально изменилось бы на сайте, если бы он не использовал Kestrel, а остался на IIS? Снаружи наверняка ничего, а внутри?
Так каких идей? Самого интересного так и не рассказали…
Рассматривали ли вариант использования Elasticsearch?
Маленькое уточнение — функция Bind приведённая выше на самом деле называется Map.
Сигнатура для функции Bind выглядит вот так:
В каких случаях необходимо задавать разные времена жизни декоратора и декорируемого?