1000 слов в активном вокабуляре и способность понимать 80% речи с любым акцентом это несовместимые утверждения. С тысячей слов вы разве что спросить как пройти в библиотеку сможете и с трудом понять что вам ответят. И да, 80% понимания это недостаточно для профессиональной коммуникации, это значит что вы не понимаете пятую часть того, что вам говорят. Просто представьте себя на встрече с заказчиком, где вам нужно что-то продать, а вы 20% слов не понимаете, ещё и не ловите контекст его шуток.
Странно слышать про "ии в принципе невозможен", когда этот ии уже работает в реальных приложениях, которыми пользуются миллионы людей. Ну то есть если бы ваша статья вышла 10 лет назад, можно было бы найти в ней смысл, но сейчас же сама реальность вас опровергает.
Ещё можете как-то прокомментировать фразу про "та-дам 50-е годы", и "воз и ныне там", как-то современная реальность использования нейросетей вообще не похожа на "и ныне там".
Касательно творчества это такая ловушка мышления. У Дмитрия Чернышёва есть прекрасные книги про то, как люди думают. Я сам посетил его курс и лично убедился, что простой набор правил и методология позволяют прокачать "творчество" даже у человека, который вообще раньше ничего сам раньше не создавал. А LLM сейчас обладает таким колоссальным объемом знаний, что просто корректный промт позволит получить от модели столько креативных и творческих вариантов, сколько обычный, даже очень творческий человек, не может даже представить.
В примере 1 у меня получается false, а не true, что я делаю не так? Ваше заявление, что если поле не используется, то оно не сохраняется, не верно.
В примере 2 вы зачем-то смешали primary constructor и immutability, как это связано? Существуют readonly struct, но, вообще-то, никто не обещал, что вместе c primary constructors введут еще и возможность ограничения классов на изменение
По уровням доступа - просто используейте обычные конструкторы, а не primary, всегда можно указать все явно. Primary constructor это синтаксический сахар, который не создан, чтобы покрывать все возможные кейсы полного синтаксиса.
В примере 3 вообще непонятна претензия, init отдельно, primary constructor отдельно. Вы сделали декларацию класса с primary constructor вместе обязательным полем с object initializer и удивляетесь, почему компилятор не позволяет вам использовать только одно из двух, называя это почему-то багом.
В документации же явно написано: primary constructor создает поля, доступные внутри описания класса. Это синтаксический сахар, которые покрывает простые кейсы для сокращения количества кода.
Не зависит. По ссылке все примеры с аутентификацией перед авторизацией. Порядок важен, и нет никакого смысла авторизовать запрос до того, как пользователь аутентифицирован.
Она может быть, а может не быть. Согласен, что подписываться на событие объекта, временем жизни которого мы не управляем, не лучшая практика. Этот пункт как раз об этом: объект вставляет ссылку на себя в объект, который приходит извне, тем самым ставя себя в зависимость от времени жизни этого объекта. Если ваш объект транзиентный, а подписывается на синглтон, например, то будет утечка.
Но в общем случае это не обязательно утечка: если мы знаем время жизни объекта, на который мы подписываемся, и понимаем отношения этого объекта с подписчиком, то вполне можно не отписываться, и оставить это на откуп GC.
Кстати, в первом пункте никакой утечки нет. Здесь экземпляр класса будет жить до тех пор, пока жив объект, на событие которого он подписан. Как только сборщик мусора доберётся до него, ваш экземпляр тоже удалится. Вот от статических событий нужно обязательно отписываться, это правда.
Забыли загрузку сборок и их динамическую генерацию. В моем опыте был случай, когда память текла из-за создания экземпляров типа Regex с опцией Compiled. С этой опцией создается динамическая сборка, которая никогда не выгружается.
Скажу как человек, побывавший много раз с обеих сторон процесса найма.
Как потенциальный кандидат, я бы отказался от выполнения такого задания. Во-первых, оно сложное для тестового задания, которое вообще-то должно читаться по диагонали за несколько минут (больше у технического интервьюера обычно нет, у него свой бэклог и дедлайны и без вас) и улетать в корзину, в лучшем случае быть началом дискуссии на самом интервью. Сложное оно причем не с алгоритмической точки зрения, а просто из-за множества однотипных кейсов типа */4, 32 число месяца и тп, которые отнимут много времени, но не дадут дополнительного value ни для кандидата, ни для проверяющего.
Как проверяющий ваш код я бы сказал, что это сразу "нет", и я очень хорошо понимаю ответ компании. Ваш код плохой для любого уровня разработчика, особенно для тестового задания на интервью, и вот почему.
.NET это все-таки про ООП, вы написали обычную простыню процедурного кода, хорошо хоть оператора goto избежали. Вы не показали ни знания, ни опыта с наследованием, полиморфизмом и инкапсуляцией.
Подобное задание предполагает использование паттернов проектирования. Вы не применили ни одного. Могли бы прикрутить какой-нибудь Builder, Strategy, Singleton, Factory method, хоть что-то, что показало бы ваш опыт работы с паттернами.
Код абсолютно неприменим в Enterprise решении: он нечитаем, неподдерживаемый и нетестируемый, в нем магические числа, у него запредельная цикломатическая сложность (собственно поэтому и нетестируемый).
Требования "не использовать много ресурсов" скорее всего это обычное требование здравого смысла, вы как минимум должны представлять временную и цикломатическую сложность вашего кода и не писать "индусский" код с циклами по одной миллисекунде. В идеале я представляею некий builder, который парсит и возвращает массив из N следующих элементов после указанного DateTime. Time complexity должно быть O(1).
Могли бы показать знание регулярных выражений, это идеальный кейс для них. Дополнительно могли бы показать, что знаете как сделать их быстрее с использованием синглтона и опции Compiled, например.
Если коротко, это код, который неприемлем в проектах enterprise уровня. И вообще он неприемлем в проектах никакого уровня, кроме очень редких кейсов погони за экономией наносекунд, типа торговых роботов, где ради лишней наносекунды можно и пренебречь красотой кода. Очевидно, что календарь это не тот случай.
Это хороший вопрос. С одной стороны, есть. С другой стороны, «промежуточное» или «связующее ПО» относится к определенному классу ПО, тогда как в статье указывается не «связующее ПО» вообще, а конкретно MVC middleware. Это не класс ПО, а конкретный термин в рамках реализации ASP.NET MVC.
Поэтому, на мой взгляд, переводить ASP.NET middleware как «промежуточное ПО» некорректно, и если нельзя найти кириллический аналог, то надо оставлять как есть.
Интересно, на своих курсах вы тоже называете middleware «промежуточным программным обеспечением»?
Обязателен ли файл startup.cs или нет? Да, startup.cs является обязательным, его можно специализировать любым модификатором доступа, например, public, private, internal.
Файл специализировать модификатором доступа?
Вы бы хоть ссылку на оригинальную статью дали, убедиться что там все так же плохо. Или это просто ваш перевод такой, что кровь из глаз.
Вообще не вижу проблемы с исключением. Лучшие практики от МС говорят, что надо обрабатывать только те исключения, которые ты ожидаешь. Если ты получаешь объект по ID, и он не найден, то на самом деле ситуации с исключением или null равноправны и зависят от логики и здравого смысла. Например, я бы ожидал исключение для условного филиала компании и null для атрибута финансового актива.
Исключения хороши, потому что гарантированно прерывают выполнение при нарушении логики. Но они дорогие, поэтому есть есть еще один паттерн, который реализован, например, в asp.net core, и о котором вы не упомянули. Этот же паттерн, по сути, реализован в Regex тоже: в качестве результата всегда возвращается объект (не исключение и не null), в котором есть свойства такие как bool Success, object Value и string Error например.
Производительность не страдает, async/await поддерживается, строгая типизация присутствует, особенно при комбинации с дженериками, возможность использовать структуры для оптимизации памяти тоже есть.
Дедлок это одна из причин, код класса не контролирует кто блокирует объект извне. Отдельный лок позволяет полностью передать контроль над блокировкой коду класса.
Другая причина в том, что если если lock(this) используется в разных методах одного класса, то выполнение одного метода будет блокировать выполнение других в случае, если обращение происходит из другого потока. Это не всегда эффективно, например, когда объект хранит несколько независимых друг от друга состояний.
Кстати, чтобы два раза не вставать, еще хуже это lock(typeof(YourType)), так как typeof() возвращает один и тот же экземпляр типа Type независимо от того, откуда он вызван, то контроль над тем кто и когда блокирует ваш код, теряется полностью.
Ни из предыдущей статьи, ни из этой не становится понятно, чем же именно плоха смс аутентификация как второй фактор. Это именно второй фактор, что предполагает, что он бесполезен, если нет первого. То есть даже если вы угнали симку, то вы не получите доступ, если не знаете логин и пароль. И вся схема работает только совместно с социальной инженерией, например.
Ну или приведите, пожалуйста, пример, как можно похитить эккаунт, только завладев симкой, без применения социальной инженерии или троянов.
1000 слов в активном вокабуляре и способность понимать 80% речи с любым акцентом это несовместимые утверждения. С тысячей слов вы разве что спросить как пройти в библиотеку сможете и с трудом понять что вам ответят. И да, 80% понимания это недостаточно для профессиональной коммуникации, это значит что вы не понимаете пятую часть того, что вам говорят. Просто представьте себя на встрече с заказчиком, где вам нужно что-то продать, а вы 20% слов не понимаете, ещё и не ловите контекст его шуток.
Странно слышать про "ии в принципе невозможен", когда этот ии уже работает в реальных приложениях, которыми пользуются миллионы людей. Ну то есть если бы ваша статья вышла 10 лет назад, можно было бы найти в ней смысл, но сейчас же сама реальность вас опровергает.
Ещё можете как-то прокомментировать фразу про "та-дам 50-е годы", и "воз и ныне там", как-то современная реальность использования нейросетей вообще не похожа на "и ныне там".
Касательно творчества это такая ловушка мышления. У Дмитрия Чернышёва есть прекрасные книги про то, как люди думают. Я сам посетил его курс и лично убедился, что простой набор правил и методология позволяют прокачать "творчество" даже у человека, который вообще раньше ничего сам раньше не создавал. А LLM сейчас обладает таким колоссальным объемом знаний, что просто корректный промт позволит получить от модели столько креативных и творческих вариантов, сколько обычный, даже очень творческий человек, не может даже представить.
Что-то вы как-то все напутали.
В примере 1 у меня получается false, а не true, что я делаю не так? Ваше заявление, что если поле не используется, то оно не сохраняется, не верно.
В примере 2 вы зачем-то смешали primary constructor и immutability, как это связано? Существуют readonly struct, но, вообще-то, никто не обещал, что вместе c primary constructors введут еще и возможность ограничения классов на изменение
По уровням доступа - просто используейте обычные конструкторы, а не primary, всегда можно указать все явно. Primary constructor это синтаксический сахар, который не создан, чтобы покрывать все возможные кейсы полного синтаксиса.
В примере 3 вообще непонятна претензия, init отдельно, primary constructor отдельно. Вы сделали декларацию класса с primary constructor вместе обязательным полем с object initializer и удивляетесь, почему компилятор не позволяет вам использовать только одно из двух, называя это почему-то багом.
В документации же явно написано: primary constructor создает поля, доступные внутри описания класса. Это синтаксический сахар, которые покрывает простые кейсы для сокращения количества кода.
Не зависит. По ссылке все примеры с аутентификацией перед авторизацией. Порядок важен, и нет никакого смысла авторизовать запрос до того, как пользователь аутентифицирован.
У вас там вызовы UseAuthentication и UseAuthorization в неправильном порядке
Она может быть, а может не быть. Согласен, что подписываться на событие объекта, временем жизни которого мы не управляем, не лучшая практика. Этот пункт как раз об этом: объект вставляет ссылку на себя в объект, который приходит извне, тем самым ставя себя в зависимость от времени жизни этого объекта. Если ваш объект транзиентный, а подписывается на синглтон, например, то будет утечка.
Но в общем случае это не обязательно утечка: если мы знаем время жизни объекта, на который мы подписываемся, и понимаем отношения этого объекта с подписчиком, то вполне можно не отписываться, и оставить это на откуп GC.
Кстати, в первом пункте никакой утечки нет. Здесь экземпляр класса будет жить до тех пор, пока жив объект, на событие которого он подписан. Как только сборщик мусора доберётся до него, ваш экземпляр тоже удалится. Вот от статических событий нужно обязательно отписываться, это правда.
Забыли загрузку сборок и их динамическую генерацию. В моем опыте был случай, когда память текла из-за создания экземпляров типа Regex с опцией Compiled. С этой опцией создается динамическая сборка, которая никогда не выгружается.
Скажу как человек, побывавший много раз с обеих сторон процесса найма.
Как потенциальный кандидат, я бы отказался от выполнения такого задания. Во-первых, оно сложное для тестового задания, которое вообще-то должно читаться по диагонали за несколько минут (больше у технического интервьюера обычно нет, у него свой бэклог и дедлайны и без вас) и улетать в корзину, в лучшем случае быть началом дискуссии на самом интервью. Сложное оно причем не с алгоритмической точки зрения, а просто из-за множества однотипных кейсов типа */4, 32 число месяца и тп, которые отнимут много времени, но не дадут дополнительного value ни для кандидата, ни для проверяющего.
Как проверяющий ваш код я бы сказал, что это сразу "нет", и я очень хорошо понимаю ответ компании. Ваш код плохой для любого уровня разработчика, особенно для тестового задания на интервью, и вот почему.
.NET это все-таки про ООП, вы написали обычную простыню процедурного кода, хорошо хоть оператора goto избежали. Вы не показали ни знания, ни опыта с наследованием, полиморфизмом и инкапсуляцией.
Подобное задание предполагает использование паттернов проектирования. Вы не применили ни одного. Могли бы прикрутить какой-нибудь Builder, Strategy, Singleton, Factory method, хоть что-то, что показало бы ваш опыт работы с паттернами.
Код абсолютно неприменим в Enterprise решении: он нечитаем, неподдерживаемый и нетестируемый, в нем магические числа, у него запредельная цикломатическая сложность (собственно поэтому и нетестируемый).
Требования "не использовать много ресурсов" скорее всего это обычное требование здравого смысла, вы как минимум должны представлять временную и цикломатическую сложность вашего кода и не писать "индусский" код с циклами по одной миллисекунде. В идеале я представляею некий builder, который парсит и возвращает массив из N следующих элементов после указанного DateTime. Time complexity должно быть O(1).
Могли бы показать знание регулярных выражений, это идеальный кейс для них. Дополнительно могли бы показать, что знаете как сделать их быстрее с использованием синглтона и опции Compiled, например.
Если коротко, это код, который неприемлем в проектах enterprise уровня. И вообще он неприемлем в проектах никакого уровня, кроме очень редких кейсов погони за экономией наносекунд, типа торговых роботов, где ради лишней наносекунды можно и пренебречь красотой кода. Очевидно, что календарь это не тот случай.
— не понимает что такое исключение
— не знает что такое race condition
— не отличает implicit и explicit casting
Мне вдруг стало интересно, что бы автор написал про async/await.
Поэтому, на мой взгляд, переводить ASP.NET middleware как «промежуточное ПО» некорректно, и если нельзя найти кириллический аналог, то надо оставлять как есть.
Файл специализировать модификатором доступа?
Вы бы хоть ссылку на оригинальную статью дали, убедиться что там все так же плохо. Или это просто ваш перевод такой, что кровь из глаз.
Всё-таки Derived, а не Delivered.
Я собеседовал огромное количество кандидатов на senior, которые не знали и половины этих тем.
Вообще не вижу проблемы с исключением. Лучшие практики от МС говорят, что надо обрабатывать только те исключения, которые ты ожидаешь. Если ты получаешь объект по ID, и он не найден, то на самом деле ситуации с исключением или null равноправны и зависят от логики и здравого смысла. Например, я бы ожидал исключение для условного филиала компании и null для атрибута финансового актива.
Исключения хороши, потому что гарантированно прерывают выполнение при нарушении логики. Но они дорогие, поэтому есть есть еще один паттерн, который реализован, например, в asp.net core, и о котором вы не упомянули. Этот же паттерн, по сути, реализован в Regex тоже: в качестве результата всегда возвращается объект (не исключение и не null), в котором есть свойства такие как bool Success, object Value и string Error например.
Производительность не страдает, async/await поддерживается, строгая типизация присутствует, особенно при комбинации с дженериками, возможность использовать структуры для оптимизации памяти тоже есть.
Другая причина в том, что если если lock(this) используется в разных методах одного класса, то выполнение одного метода будет блокировать выполнение других в случае, если обращение происходит из другого потока. Это не всегда эффективно, например, когда объект хранит несколько независимых друг от друга состояний.
Кстати, чтобы два раза не вставать, еще хуже это lock(typeof(YourType)), так как typeof() возвращает один и тот же экземпляр типа Type независимо от того, откуда он вызван, то контроль над тем кто и когда блокирует ваш код, теряется полностью.
А автор точно знает как перебирать массивы? После такого
for (i = 0; i < 9; i++) {
для массива из 10 элементов в этом очень большие сомнения.
Ни из предыдущей статьи, ни из этой не становится понятно, чем же именно плоха смс аутентификация как второй фактор. Это именно второй фактор, что предполагает, что он бесполезен, если нет первого. То есть даже если вы угнали симку, то вы не получите доступ, если не знаете логин и пароль. И вся схема работает только совместно с социальной инженерией, например.
Ну или приведите, пожалуйста, пример, как можно похитить эккаунт, только завладев симкой, без применения социальной инженерии или троянов.