Не приведена полная схема базы, непонятно какой размер текста средний. Для сортировки логично было бы добавить индекс по Name, иначе она будет отъедать все время, или хотя бы сравнить время с сортировкой по id. По опыту с SQL Server такой поиск может работать очень быстро.
Непонятно, что имеется ввиду, при желании можно достать из EF нужную информацию и написать любой тест. Ну и на фоне того, что делает внутри себя EF создание рекорда можно сказать ничего не стоит.
Да, это странно, реализация практически один-в-один совпадает с С#, но там таких пазлов нет. Вероятно у них какие-то свои соображения были, хотелось бы знать какие.
Код слева мог бы быть ОК, но если вчитаться, то ничего хорошего в нем нет, в итоге код справа только усугубляет проблемы левой части. Нет обработки ситуации когда kind пришел неизвестный (да и вообще нет обработки ошибок), странные интерфейсы у печи, коробки и тд, вместо oven.Bake(anything, time) написан код, который будет дублирован везде, непонятно зачем нужен флаг Baked, box.SlicePizza - это прям что-то странное. Это все не имеет даже отношения к конкретному языку.
Это все верно, но только потому, что в итоге получилась такая реализация и тип операции передается явно, поэтому в многих случаях этот код можно заменить на более привычные вещи. Полноценно это можно сделать сейчас только для своих типов с помощью static abstract методов в интерфейсах, тогда достаточно указать что T : IAppendable<T>.
Это в каком-то смысле неудивительно, тоже самое происходит с фейсбуком, нетфликсом, твитер пытается выползти на окупаемость (непонятно, о чем они думали до того, как их купил Маск). Просто потому, что деньги и ресурсы не есть гарантия создания успешного продукта.
Дело в том, что гугл не занимается поиском в привычном понимании, у них ИИ алгоритм, который решает, что вам нужнее. Насколько эта вещь беспомощная можно наблюдать на ютьюбе.
Было интересно пройти тесты. Что касается русского, то он явно смещен в заимствования и устаревшие слова, то есть измеряет скорее груз, а не запас (вероятность услышать некоторые слова в течение всей жизни практически равна нулю). Ангийский же получается смещен в сторону тех, кто учил недавно или учит по словарю. Оба теста недостаточно проверяют действительно ли испытуемый знает значение, просто кликая некст я выбил 22 тысячи по английскому.
Неплохая идея. В SQL Server есть механизм снепшотов, по сути такие сейв-пойнты, можно сделать снепшот и после теста вернутся в исходное состояние и обойтись без рестартов, может есть ли что-либо похоже в postgresql?
Снова подкинули задачу на связанную тему, и вот что мне пришло в голову, почему бы не использовать эксел-подобные формулы (туда даже лямбды завезут скоро:))?
Не знаю, какие-то смешанные чувства по этому поводу. Чисто с практической стороны сигналы нужны относительно редко, но нам придется весь код завернуть в них, что может и быстрее, но сложнее, чем старый подход. Прибили гвоздями их к фреймворку, а это делает практически невозможным их нормальное развитие, они не могут себе позволить ломать совместимость. Лучше было бы, если бы сделали некий интерфейс для подключения любых реализаций реактивности и вынесли свои сигналы в отдельный пакет.
There is currently no built-in integration of signals with ngModel so the only way for now is using [ngModel]="filter()" (ngModelChange)="filter.set($event)"
Понятно, что есть Facade, что можно разрезать на пару контроллеров, но смысл? Контроллер группирует запросы (а мы их наоброт раскидаем, тестировать проще, SRP, но теперь больше однотипного кода, пачка файлов и дублированные префиксы роутов и верятно еще что-то), а вынос в Facade ничем сильно не помогает, все равно будут создаваться ненужные для конкретного запроса сервисы, да и переиспользовать его маловероятно.
И каким образом можно решить эту проблему с контроллером? Как ни крути ничего хорошего не выйдет. Худо-бедно разве что с помощью внедрения в экшн-метод используя FromServices.
Вобще, разработчик не может в принципе сам закладывать "гибкость", если ему не сообщили о возможных сценариях, и архтектура тут ничем не может помочь, просто сложится так, что какие-то вещи будет добавить легко, а какие-то потребуют кардинальных изменений.
Надо сказать, что вот эти все "должно быть через месяц" для разработчика являются красным флагом - с такой канторы надо бежать, и ладно, если вы просто гребец - можно сделать лицо кирпичом и веслать в обычном темпе, а если тимлид, то лучше сразу уволится :)
А в API это будет доступно?
Не приведена полная схема базы, непонятно какой размер текста средний. Для сортировки логично было бы добавить индекс по Name, иначе она будет отъедать все время, или хотя бы сравнить время с сортировкой по id. По опыту с SQL Server такой поиск может работать очень быстро.
Непонятно, что имеется ввиду, при желании можно достать из EF нужную информацию и написать любой тест. Ну и на фоне того, что делает внутри себя EF создание рекорда можно сказать ничего не стоит.
Да, это странно, реализация практически один-в-один совпадает с С#, но там таких пазлов нет. Вероятно у них какие-то свои соображения были, хотелось бы знать какие.
Код слева мог бы быть ОК, но если вчитаться, то ничего хорошего в нем нет, в итоге код справа только усугубляет проблемы левой части. Нет обработки ситуации когда kind пришел неизвестный (да и вообще нет обработки ошибок), странные интерфейсы у печи, коробки и тд, вместо oven.Bake(anything, time) написан код, который будет дублирован везде, непонятно зачем нужен флаг Baked, box.SlicePizza - это прям что-то странное. Это все не имеет даже отношения к конкретному языку.
Это все верно, но только потому, что в итоге получилась такая реализация и тип операции передается явно, поэтому в многих случаях этот код можно заменить на более привычные вещи. Полноценно это можно сделать сейчас только для своих типов с помощью static abstract методов в интерфейсах, тогда достаточно указать что T : IAppendable<T>.
И как же сделать, так чтобы, например, string реализовывал IPohooy<T> ?
Зачем они наложили это ограничение в виде standalone: true?? О чем они вобще только думали когда это делали, у меня посто слов нет.
А кто расставляет эти веса? И еще спрошу, какие веса отвечают за выдачу в ютюбе, который выдает вобще нерелевантные вещи.
Это в каком-то смысле неудивительно, тоже самое происходит с фейсбуком, нетфликсом, твитер пытается выползти на окупаемость (непонятно, о чем они думали до того, как их купил Маск). Просто потому, что деньги и ресурсы не есть гарантия создания успешного продукта.
Дело в том, что гугл не занимается поиском в привычном понимании, у них ИИ алгоритм, который решает, что вам нужнее. Насколько эта вещь беспомощная можно наблюдать на ютьюбе.
Было интересно пройти тесты. Что касается русского, то он явно смещен в заимствования и устаревшие слова, то есть измеряет скорее груз, а не запас (вероятность услышать некоторые слова в течение всей жизни практически равна нулю). Ангийский же получается смещен в сторону тех, кто учил недавно или учит по словарю. Оба теста недостаточно проверяют действительно ли испытуемый знает значение, просто кликая некст я выбил 22 тысячи по английскому.
Может наконец подтолкнет пользоваться открытыми решениями либо делать что-то свое.
Неплохая идея. В SQL Server есть механизм снепшотов, по сути такие сейв-пойнты, можно сделать снепшот и после теста вернутся в исходное состояние и обойтись без рестартов, может есть ли что-либо похоже в postgresql?
Снова подкинули задачу на связанную тему, и вот что мне пришло в голову, почему бы не использовать эксел-подобные формулы (туда даже лямбды завезут скоро:))?
Не знаю, какие-то смешанные чувства по этому поводу. Чисто с практической стороны сигналы нужны относительно редко, но нам придется весь код завернуть в них, что может и быстрее, но сложнее, чем старый подход. Прибили гвоздями их к фреймворку, а это делает практически невозможным их нормальное развитие, они не могут себе позволить ломать совместимость. Лучше было бы, если бы сделали некий интерфейс для подключения любых реализаций реактивности и вынесли свои сигналы в отдельный пакет.
Добрый вечер...
Понятно, что есть Facade, что можно разрезать на пару контроллеров, но смысл? Контроллер группирует запросы (а мы их наоброт раскидаем, тестировать проще, SRP, но теперь больше однотипного кода, пачка файлов и дублированные префиксы роутов и верятно еще что-то), а вынос в Facade ничем сильно не помогает, все равно будут создаваться ненужные для конкретного запроса сервисы, да и переиспользовать его маловероятно.
И каким образом можно решить эту проблему с контроллером? Как ни крути ничего хорошего не выйдет. Худо-бедно разве что с помощью внедрения в экшн-метод используя FromServices.
Вобще, разработчик не может в принципе сам закладывать "гибкость", если ему не сообщили о возможных сценариях, и архтектура тут ничем не может помочь, просто сложится так, что какие-то вещи будет добавить легко, а какие-то потребуют кардинальных изменений.
Надо сказать, что вот эти все "должно быть через месяц" для разработчика являются красным флагом - с такой канторы надо бежать, и ладно, если вы просто гребец - можно сделать лицо кирпичом и веслать в обычном темпе, а если тимлид, то лучше сразу уволится :)