В том-то и дело, что Яндексу не нужен опыт. Нужна голова и способность принять условия игры. Несколько раз сказали — выучи, повтори алгоритмы. Если (а) согласишься (б) успешно и быстро подтянешь — то потом, когда тебе скажут разобраться с «Яндекс.Велосипедофреймворк», ты (а) не будешь спорить (б) быстро разберешься.
Есть теория, что Яндекс понимает кого ищет.
Ищет людей с хорошим знанием алгоритмов и привычкой всюду смотреть на O(?).
Как найдет, дальше всему научит сам.
Мне такой подход не близок, но я не Яндекс.
Про то, что спрашивать про джанго на собеседованиях не нужно, я как раз с Яндексом согласен. Если ты крутой, дадут методичку, выучишь.
Про ваш пример про парусник. Интересно, что развитие показало, что авторы парусника были концептуально правы.
Сейчас гигантские корабли почти полностью автоматизированы, и там, где была раньше толпа кочегаров и сменные on-call механики, на судне ровно один механик, который вахту не стоит, а занимается обслуживанием, профилактикой и ремонтом.
Например, Торвальдс приводит вот в своей автобиографии две причины:
Отношение к успешным. Положим, у А были средние результаты за год, у Б — очень хорошие. В США: А з/п останется такой-же, Б получит большую премию, новый грейд, + 30% к зарплате. В Финляндии: А получит +1% к зарплате, Б получит +1.5%
«После 16-00 на улицах темно и страшно, ходят только напившиеся водки старушки»
Почему «забыла»? А вот веб-фреймворк от MS держит первое место по бенчмарку https://www.techempower.com/benchmarks/#section=data-r19&hw=ph&test=plaintext Этот аргумент имеет ТАКОЕ ЖЕ отношение к ядру, как и просмотрщик фото (то есть никакое), но если вы воспринимаете аргумент про просмотрщик фото, то примите и этот.
А с ядром-то какая связь?
Попробуйте добиться детерминированности поведения Windows 10 по аналогии с описанным в статье на XP. Покажите время реакции на уровне десятков-сотен миллисекунд, как в XP.
Windows никогда не была, не будет и не планируется RTOS.
Какая разница. сколько весит просмотр фотографии? Может наоборот за счет того, что меньше ресурсов программистов потрачено на создание просмотрщика фотографий, удается освободить больше ресурсов на вылизывание ядра?
Современные браузерные движки (к разговору про Electron) сложные программы, активно использующие низкоуровневые API и предъявляющие жесткие требования к ядру. Так что курсу на производительности это опять не мешает.
Мы же тут не на пикабу прости господи, а технические люди. Какие аргументы есть за «Windows плевать на качество ядра»?
Я поддерживаю в принципе ваш подход мол DbSet это репозиторий. Но практика показывает, что ВООБЩЕ говоря этот подход далеко не единственный, и (а) есть много людей, который предпочитают делать абстрации над EF и (б) есть например подход clean archirecture, который предусматривает, что бизнес-логика не может зависеть от репозитория (а репозиторий должен уметь загружать и сохранять доменные объекты).
Опять же про интерфейс. Во-первых, есть подход clean architecture (например в домене объявляются интерфейсы, а в зависимых проектах DAL реализуются). Во-вторых, моки, тестирование etc
Про IRepository<T>. Его-то как раз кмк нет смысла объявлять (потому что это полный аналог DbSet), а вот в IAlbumRepository могут начать появляться методы вроде LoadAlbumsByAuthor и тогда его использование станет более оправдано.
Disposable И тут скорее согласен. При DI подходе не дело управлять временем жизни объекта вручную, САМ контекст при этом может быть вполне IDisposable, но ни к чему этому знанию протекать в интерфейс.
Итого я скорее с вами согласен, но не согласен в том, что это прям ужас-ужас. Многие так пишут, и могут быть причины так писать в рамках многих подходов.
В том-то и дело, что Яндексу не нужен опыт. Нужна голова и способность принять условия игры. Несколько раз сказали — выучи, повтори алгоритмы. Если (а) согласишься (б) успешно и быстро подтянешь — то потом, когда тебе скажут разобраться с «Яндекс.Велосипедофреймворк», ты (а) не будешь спорить (б) быстро разберешься.
Есть теория, что Яндекс понимает кого ищет.
Ищет людей с хорошим знанием алгоритмов и привычкой всюду смотреть на O(?).
Как найдет, дальше всему научит сам.
Мне такой подход не близок, но я не Яндекс.
Про то, что спрашивать про джанго на собеседованиях не нужно, я как раз с Яндексом согласен. Если ты крутой, дадут методичку, выучишь.
Про ваш пример про парусник. Интересно, что развитие показало, что авторы парусника были концептуально правы.
Сейчас гигантские корабли почти полностью автоматизированы, и там, где была раньше толпа кочегаров и сменные on-call механики, на судне ровно один механик, который вахту не стоит, а занимается обслуживанием, профилактикой и ремонтом.
Что за хрень? ASP.NET Core это докер образ + перед ним нужно прокси-сервер.
Ну, у меня есть мой кластер, где я храню всякое.
А есть helm-chart или что-нибудь такое, чтобы без геморроя поставить в k8s? У меня есть кластер...
Любое решение, подразумевающее форк, выкидывает все разговоры о децентрализации в корзину
Изначально в Rust был встроенный GC, и есть разные варианты GC для Rust.
Например, Торвальдс приводит вот в своей автобиографии две причины:
Отношение к успешным. Положим, у А были средние результаты за год, у Б — очень хорошие. В США: А з/п останется такой-же, Б получит большую премию, новый грейд, + 30% к зарплате. В Финляндии: А получит +1% к зарплате, Б получит +1.5%
«После 16-00 на улицах темно и страшно, ходят только напившиеся водки старушки»
И еще надо добавить, что эти заказчики, пользуясь своей рыночной силой, потом будут выкручивать тебе руки на раздувание скоупа проекта.
Как я и говорил, Windows — не RTOS.
В огороде бузина, а в киеве дядька.
Мы же тут не на пикабу прости господи, а технические люди. Какие аргументы есть за «Windows плевать на качество ядра»?
Я не фанат Electron. Но при чем тут это к обсуждению про ядро?
При чем здесь Electron, если разговор про ядро?
Хранят-хранят.
Я поддерживаю в принципе ваш подход мол DbSet это репозиторий. Но практика показывает, что ВООБЩЕ говоря этот подход далеко не единственный, и (а) есть много людей, который предпочитают делать абстрации над EF и (б) есть например подход clean archirecture, который предусматривает, что бизнес-логика не может зависеть от репозитория (а репозиторий должен уметь загружать и сохранять доменные объекты).
Опять же про интерфейс. Во-первых, есть подход clean architecture (например в домене объявляются интерфейсы, а в зависимых проектах DAL реализуются). Во-вторых, моки, тестирование etc
Про
IRepository<T>. Его-то как раз кмк нет смысла объявлять (потому что это полный аналог DbSet), а вот вIAlbumRepositoryмогут начать появляться методы вродеLoadAlbumsByAuthorи тогда его использование станет более оправдано.Disposable И тут скорее согласен. При DI подходе не дело управлять временем жизни объекта вручную, САМ контекст при этом может быть вполне IDisposable, но ни к чему этому знанию протекать в интерфейс.
Итого я скорее с вами согласен, но не согласен в том, что это прям ужас-ужас. Многие так пишут, и могут быть причины так писать в рамках многих подходов.
Расскажите, что тут не так с вашей точки зрения. А то много идей
А почему тут заминусован коммент? Мог бы кто-нибудь аргументированно возразить? Кажется, важный вопрос поднят.
Славные были времена, с ностальгией вспоминаю регионы внутри регионов.
Только ник у меня сходится Глеб Л., а фамилия в профиле нет.
А название исследовательского центра не начинается с P?