Они только выглядят так, по языку и менталитету — австралийцы от мозга до костей. Большинство не говоярт по китайски и даже знать не хотят о родине родителей.
Если это позволит более эффективно бороться с криминалом и терроризмом, то почему бы и нет? Мне, как и большинству населения нечего скрывать. Ну подсмотрят где я шмотки заказываю и в какие кинотеатры хожу, и что? Это небольшая плата за более безопасное общество, не говоря уже что в последствии это позволит сократить расходы на безопасность и пустить их на ту же медицину и науку. Это в России слежка используется для подавления инакомыслия и поиску врагов режима, в Британии такой херней не страдают, а если бы страдали, такой бы вой поднялся, мама не горюй.
Код пишет один, а читают и поддерживают его многие. Так что на первом месте должна быть простота, понятность, прогнозируемость, слабая связанность (чтобы в случае чего код можно было безопасно переписать или выкинуть не затрагивая другие компоненты) и дружелюбие к дебагингу. А вот во сколько строк кода это выльется — это уже второстепенное. Уж лучше читать простой, прогнозируемый, линейный код хоть и с небольшим копипастом, чем писанину и дизайн в стиле «смотри как я могу!».
И потом таскать толстый, тяжелый кирпич? При обычном городском стиле жизни, зарядка раз в сутки не проблема. Не говоря уже что зарядиться можно от любого ЮСБ причем за пол часа-час если есть поддержка fast charge. Не говоря уже что по слухам новый iPhone будет заряжаться от беспроводной зарядки с радиусом действия 4.5 метра. Короче вы смотрите назад, а не вперед )
Для редких экстренных случаев, ну там путешествия или вылазка на природу, есть внешние аккумуляторы. Да и просто в рюкзак бросить power bank на всякий случай, и все. Все же луче чем на телефоне в штанах постоянно его таскать.
Если вам такое будущее не нравится, ну что же, голосуйте рублем за уродливые, кирпичные блоки. Радует что вас таких немного :)
2. Много памяти. На многих чипах есть 4 канала uSD — телефон с 4мя флешками очень оценят любители музыки и кино,
Любители кино не будут себя насиловать смотреть фильм на смартфоне :). Есть флешки на 128 гб, полная поддержка флешек на 1 тб лишь вопрос времени, не понимаю чего вам не хватает. Я вот за три года 32 гб только на половину забил :). Ну да, я не смотрю фильмы на телефоне (для этого есть кинотеатр, телик, а в дороге планшет/ноут) и не играю в тяжелые игры (для этого есть комп и плейстейшн).
3. Красивые недорогие «звонилки» на много симок (2/3/4).
На алиэкспресе полно. Голосуйте рублем, тогда нормальные производители подтянутся :).
Обычному человеку вообще достаточно не делать откровенных глупостей типа использовать пароли вида 111, записывать пин коды на карточках или вбивать свои карточные данные на подозрительных сайтах. Чтобы было на душе спокойно, достаточно использовать менеджер паролей (включая проприетарные) с мудренным master паролем и хранить секретные записи там. Добавить двухфакторную авторизацию для почты и основных банковских счетов. Все что больше — для важных персон и параноиков, ИМХО. Народ выше вот из соц сетей удаляется, почтой, поисковиками не пользуется, использует звонилки вместо смартфонов — это же ппц. Шапочки из фольги еще не хватает.
Сюда бы еще Алена добавить. Голова это как оперативка — чем больше вы в ней держите, тем сложнее вам работать и концентрироваться на текущих задачах, так-как постоянно нужно помнить сделать то и се и желательно к такому то времени. Поэтому важно задампить вашу оперативку на что-то более надежное, а именно выписать все задачи и планы куда-то и регулярно пересматривать, приоритезировать и планировать ваши дни, недели. Лично я для этих целей использую doit.im.
Как писал Карнеги, для полного счастья нужна еда, крыша над головой, здоровье, деньги, которые позволяли бы обеспечить минимальные потребности, и… чувство собственной важности. Никакая зарплата так не мотивирует сотрудника, как похвалы от более авторитетных коллег и понимание того, что другие получают меньше, а значит менее ценнее чем ты. Даже высокая зарплата не будет радовать, если ты знаешь что коллега сидящий рядом с тобой, получает больше, особенно если ты считаешь коллегу хуже себя. То же самое и с миллионерами. Ну получил ты несколько миллионов, что дальше? Некоторые за то же самое получили несколько десятков миллионов. Ламборгини только на время повысит это чувство собственной важности, пока не придет осознания того, что другим то по большему счету пофиг что там у тебя. Маск вот тоже за первый лям МкЛарен купил, но потом понял что счастье в другом, в создании чего-то, что бы принесло признание людей.
«Написать код понятный машине это фигня, а вот написать код понятный человеку — это исскуство» (с) не помню кто
ИМХО, если нет супер критических требований по производительности, можно забить на все эти оптимизации по уменьшению количеству проходов по циклам, условий и т.д… На первом месте должна стоять простота, читабельность и понятность кода, даже в ущерб производительности и меньшему объему кода (понятное дело что совсем маргиналить с трема влоежными циклами или еще чем-то — не надо). В 90% задачах разницы в скорости все-равно не будет видно а более короткий код далеко не всегда более читабельный код.
Автор либо троль, либо решил самоутвердиться за счет рекрутера
Буквально с первых вопросов стало понятно что это обычный HR скриннинг и что рекрутер не в теме. Поэтому, оставалось два варианта:
1. Отвечать то, что рекрутер хотел услышать и не выпендриваться;
2. Бросить трубку со словами «Вы ошиблись кандидатом», ибо работников с таким опытом на такие должности так не нанимают, ихняя репутация идет впереди них и как таковых собеседований не проводится, максимум обсуждение условий сотрудничества.
Учитывая опыт кандидата, я бы выбрал второй вариант
Большинство книг об одном и том же. Достаточно прочитать несколько книг из разных областей и начать наконец-то что-то менять в своей жизни, действовать, следовать описанным принципам, многие из которых очевидные. Читать и ничего не делать = не читать. Ну и естественно своя голова на плечах должна быть.
Можно, конечно, писать эти условия Where прямо в контроллере, но это примерно то же самое, что и писать там непосредственно SQL-запросы.
Большая разница, linq типизированное а SQL запросы нет
Посмотрите сами на этот код. А если там будет больше условий и если вы не писали этот запрос, как вам понять, что он делает, быстро? И сравните его с понятным названием метода, и тогда вы, возможно, поймете, зачем используются репозитории (или сервисы, кто как любит).
Ну выносите запрос в приватный метод класса где он реально используется, делов то. Есть же полно способов навести красоту )
Также представьте, что вы написали несколько таких конструкций по проекту, а затем вам поступает задача изменить условие с БОЛЬШЕ на БОЛЬШЕ ИЛИ РАВНО. И что тогда? Будете везде лазить и изменять. И так делают, к сожалению, большинство.
Опять же, есть куча способов такие ситуации разрулить, например те же экстеншн методы о которых я упоминал. В этом то и вся суть, у вас полно пространства для маневров, вы не связываете себе руки и к каждой конкретной ситуации подходите отдельно. Если же вы решили связаться со своим репозиторием над EntityFramework, у вас выбора особого не остается — чуть что или новый репозиторий или новый метод в репозитории, потом к нему тесты, документация, и т.д.
По поводу EF уже абстракция повторюсь, существует не только EF. Посмотрите хотя бы на пример. Если вы на 100% уверены, что вашему проекту не потребуется что-то другое и знаете, что его ждет дальше — прекрасно, можно все упростить и использовать напрямую DbContext и linq-запросы в контроллерах.
Я на 100% уверен что если что-то такое произойдет, что потребует отказаться от EF, то это не обойдется простым написанием новых репозиториев. Можно конечно написать совершенную изоляцию слоя данных, но а) правильную изоляцию сделать сложно и довольно затратно; б) эффективность и производительность будет хуже. Так что это компромисс, кому что лучше ).
Если есть часто используемые запросы в базу которые хочется переиспользовать, можно в extension методы вынести.
EntityFreamwork сам по себе уже абстракция которая отделяет данные от всего приложения. Хоть убейте не понимаю как набор IBlaBlaRepository с кучей методов в каждом из них, лучше «разделяет приложение» чем одна IDbContextFactory которая создает DbContext с набором IQueryable.
Как правильно выше пишут, EntityFramework сам по себе уже и UnitOfWork и репозиторий и всякие абстракции над ним не несут ничего кроме избыточности и связывания рук. Достаточно добавить парочку интерфейсов над DbContext чтобы можно было его пропихивать через DI контейнер и все.
Абстракции можно оправдать только одним аргументом — возможность в будущем заменить EntityFramework на что-то другое, или вообще избавится от реляционной базы данных в пользу чего то другого. Но,
1. На практике это происходит очень редко;
2. Если это происходит, обычно простым написанием новых IBlaBlaRepository не обойтись — все-равно придется пол проекта перелапачивать чтобы эффективно использовать новый DAL и базу.
Там комментариев и документации больше чем кода. Убрать все лишнее и будет 200 строк.
Я не о том полезный код или нет. Я о том, что в джаваскрипт мире хайп делают из ничего, из того что можно свелосипедить за пол дня и забыть, вместо того чтобы тащить 101-ую зависимость в проект со всеми вытекающими, читать мануалы по ней, разбираться почему не работает, дебажить, и т.д…
И потом таскать толстый, тяжелый кирпич? При обычном городском стиле жизни, зарядка раз в сутки не проблема. Не говоря уже что зарядиться можно от любого ЮСБ причем за пол часа-час если есть поддержка fast charge. Не говоря уже что по слухам новый iPhone будет заряжаться от беспроводной зарядки с радиусом действия 4.5 метра. Короче вы смотрите назад, а не вперед )
Для редких экстренных случаев, ну там путешествия или вылазка на природу, есть внешние аккумуляторы. Да и просто в рюкзак бросить power bank на всякий случай, и все. Все же луче чем на телефоне в штанах постоянно его таскать.
Если вам такое будущее не нравится, ну что же, голосуйте рублем за уродливые, кирпичные блоки. Радует что вас таких немного :)
Любители кино не будут себя насиловать смотреть фильм на смартфоне :). Есть флешки на 128 гб, полная поддержка флешек на 1 тб лишь вопрос времени, не понимаю чего вам не хватает. Я вот за три года 32 гб только на половину забил :). Ну да, я не смотрю фильмы на телефоне (для этого есть кинотеатр, телик, а в дороге планшет/ноут) и не играю в тяжелые игры (для этого есть комп и плейстейшн).
На алиэкспресе полно. Голосуйте рублем, тогда нормальные производители подтянутся :).
ИМХО, если нет супер критических требований по производительности, можно забить на все эти оптимизации по уменьшению количеству проходов по циклам, условий и т.д… На первом месте должна стоять простота, читабельность и понятность кода, даже в ущерб производительности и меньшему объему кода (понятное дело что совсем маргиналить с трема влоежными циклами или еще чем-то — не надо). В 90% задачах разницы в скорости все-равно не будет видно а более короткий код далеко не всегда более читабельный код.
Буквально с первых вопросов стало понятно что это обычный HR скриннинг и что рекрутер не в теме. Поэтому, оставалось два варианта:
1. Отвечать то, что рекрутер хотел услышать и не выпендриваться;
2. Бросить трубку со словами «Вы ошиблись кандидатом», ибо работников с таким опытом на такие должности так не нанимают, ихняя репутация идет впереди них и как таковых собеседований не проводится, максимум обсуждение условий сотрудничества.
Учитывая опыт кандидата, я бы выбрал второй вариант
Правда не подходит для фундаментальных книг — с графиками, таблицами, формулами
Большая разница, linq типизированное а SQL запросы нет
Ну выносите запрос в приватный метод класса где он реально используется, делов то. Есть же полно способов навести красоту )
Опять же, есть куча способов такие ситуации разрулить, например те же экстеншн методы о которых я упоминал. В этом то и вся суть, у вас полно пространства для маневров, вы не связываете себе руки и к каждой конкретной ситуации подходите отдельно. Если же вы решили связаться со своим репозиторием над EntityFramework, у вас выбора особого не остается — чуть что или новый репозиторий или новый метод в репозитории, потом к нему тесты, документация, и т.д.
Я на 100% уверен что если что-то такое произойдет, что потребует отказаться от EF, то это не обойдется простым написанием новых репозиториев. Можно конечно написать совершенную изоляцию слоя данных, но а) правильную изоляцию сделать сложно и довольно затратно; б) эффективность и производительность будет хуже. Так что это компромисс, кому что лучше ).
не пришлось на интерфейс и реализацию вешать это:
Если есть часто используемые запросы в базу которые хочется переиспользовать, можно в extension методы вынести.
EntityFreamwork сам по себе уже абстракция которая отделяет данные от всего приложения. Хоть убейте не понимаю как набор IBlaBlaRepository с кучей методов в каждом из них, лучше «разделяет приложение» чем одна IDbContextFactory которая создает DbContext с набором IQueryable.
Абстракции можно оправдать только одним аргументом — возможность в будущем заменить EntityFramework на что-то другое, или вообще избавится от реляционной базы данных в пользу чего то другого. Но,
1. На практике это происходит очень редко;
2. Если это происходит, обычно простым написанием новых IBlaBlaRepository не обойтись — все-равно придется пол проекта перелапачивать чтобы эффективно использовать новый DAL и базу.
Я не о том полезный код или нет. Я о том, что в джаваскрипт мире хайп делают из ничего, из того что можно свелосипедить за пол дня и забыть, вместо того чтобы тащить 101-ую зависимость в проект со всеми вытекающими, читать мануалы по ней, разбираться почему не работает, дебажить, и т.д…