Можно залезть в спеки питона и натаскать еще десяток уникальных примеров кода, объявить их базовой базой - а вот потому что я так решил - знаешь эти случаи - знаешь базу, а нет ну и катись колбаской.
Так знания не проверяют - так почесывают ЧСВ, за счет отсеивания тех кому не повезло (ну или повезло, тут как посмотреть)
Ложь - 90% это именно вопросы ловушки, про то, что в живом и минимально адекватном коде не встречается. Соответственно если кандидат не зубрила и не говнокодер, для которого увидеть/написать аналог примера с наследованием ежедневная рутина - он ваше собеседование не пройдет - потому-что "накрутил" опыт.
Если интервьюер для проверки базового понимания языка использует не рабочую кодовую базу или, на худой конец, OpenSource репу какой-нибудь тулзы - он априори, чудак на букву м.
И единственный валидный совет - держаться от компании и такого интервьюера желательно подальше.
Оптимальный подход к работе с T-SQL в .NET Core EF Core - это гибридный подход.
Оптимальный подход к работе с T-SQL в EF - не использовать T-SQL в EF.
Он там просто не нужен: - Если у нас низконагруженное приложение, то можно просто забить на неоптимальность некоторых запросов - MSSQL достаточно производительная СУБД. - Если кровавый Ынтырпрайз, то все тяжелые штуки отдаются на откуп программисту бд, который сделает оптимизированные по самое нехочу хранимые процедуры - останется просто вызвать. - А если что-то специфичное, то сразу берем Dapper и пользуемся всеми особенностями диалекта T-SQL
unity давно и прочно оккупировал мобилки и индюшатину, в этой области это много более популярный движок, чем unreal. А в статье, насколько я понял, как раз и говорится про мобилки и игры категории Б.
Поэтому потрогать движок отожравший 3/4 целевого рынка, а потом уйти в довольно узкий сегмент, потому-что "уперся в потолок" - как минимум, звучит забавно.
В 2019-м я впервые запустил Unity. Потыкал пару месяцев, сделал пару смешных проектов, и всё — почувствовал потолок. Захотелось чего‑то посерьёзнее, и я пересел на Unreal Engine 4.
В 2007 я впервые запустил C++. Потыкал пару месяцев, сделал пару смешных проектов, и все - почувствовал потолок. Захотелось чего-то посерьезнее, и я пересел на Хаскель.
Асинхронно значит несколько другое, отсутствие ожидание имеется в наличии и в параллельном коде и в асинхронном)) Кому тут нужно подтягивать знания - большой вопрос.
В контексте дефолтного планировщика Task.Run - запустит задачу параллельно и все что мы можем - это асинхронно дождаться ее выполнения. Т.е. в целом речь шла о том что Task и Thread нельзя четко разделить, что одно всегда асинхронное, а второе всегда параллельное.
Асинхронность в шарпе существовала и до появления async/await и даже до появления Task (APM и EAP жуткие штуки, но они имеют место быть)
Вобще выглядит так, что в списке достижений не хватает пункта: - Создал собственную ОС с нескучными обоями
Тимлид должность, в том числе административная, где управленческие навыки и навыки работы с людьми выходят на первое место. Откуда они у 17 летнего юноши, который даже старостой в группе универа не побывал, не говоря о большем.
Да даже если бы у него в 17 лет был красный диплом МГУ - все равно на должность тимлида он не тянул, но возможно, в таком случае, вполне неплохо бы смотрелся на должности техлида.
Все в курсе что виртуализация данных давно есть и в реакте и в вуе и даже в ангуляре (ужас-ужас что делается). Но некоторые фронтендщики настолько зациклены в своем манямирке, что в принципе не способны понять весь юмор происходящего...
Если CLR виртуальная машина для шарпа, то по этой логике - libc это виртуальная машина для си :D
Да нет тут понимания языка. Ну вот вобще нет.
Можно залезть в спеки питона и натаскать еще десяток уникальных примеров кода, объявить их базовой базой - а вот потому что я так решил - знаешь эти случаи - знаешь базу, а нет ну и катись колбаской.
Так знания не проверяют - так почесывают ЧСВ, за счет отсеивания тех кому не повезло (ну или повезло, тут как посмотреть)
Ложь - 90% это именно вопросы ловушки, про то, что в живом и минимально адекватном коде не встречается. Соответственно если кандидат не зубрила и не говнокодер, для которого увидеть/написать аналог примера с наследованием ежедневная рутина - он ваше собеседование не пройдет - потому-что "накрутил" опыт.
Если интервьюер для проверки базового понимания языка использует не рабочую кодовую базу или, на худой конец, OpenSource репу какой-нибудь тулзы - он априори, чудак
на букву м.И единственный валидный совет - держаться от компании и такого интервьюера желательно подальше.
Писать в хабе PHP про LINQ в стиле 1С - это сильно. Я бы даже сказал это чертовски смело...
Оптимальный подход к работе с T-SQL в EF - не использовать T-SQL в EF.
Он там просто не нужен:
- Если у нас низконагруженное приложение, то можно просто забить на неоптимальность некоторых запросов - MSSQL достаточно производительная СУБД.
- Если кровавый Ынтырпрайз, то все тяжелые штуки отдаются на откуп программисту бд, который сделает оптимизированные по самое нехочу хранимые процедуры - останется просто вызвать.
- А если что-то специфичное, то сразу берем Dapper и пользуемся всеми особенностями диалекта T-SQL
unity давно и прочно оккупировал мобилки и индюшатину, в этой области это много более популярный движок, чем unreal. А в статье, насколько я понял, как раз и говорится про мобилки и игры категории Б.
Поэтому потрогать движок отожравший 3/4 целевого рынка, а потом уйти в довольно узкий сегмент, потому-что "уперся в потолок" - как минимум, звучит забавно.
В 2007 я впервые запустил C++. Потыкал пару месяцев, сделал пару смешных проектов, и все - почувствовал потолок. Захотелось чего-то посерьезнее, и я пересел на Хаскель.
Асинхронно значит несколько другое, отсутствие ожидание имеется в наличии и в параллельном коде и в асинхронном)) Кому тут нужно подтягивать знания - большой вопрос.
В контексте дефолтного планировщика Task.Run - запустит задачу параллельно и все что мы можем - это асинхронно дождаться ее выполнения. Т.е. в целом речь шла о том что Task и Thread нельзя четко разделить, что одно всегда асинхронное, а второе всегда параллельное.
Асинхронность в шарпе существовала и до появления async/await и даже до появления Task (APM и EAP жуткие штуки, но они имеют место быть)
Wat? И давно это вдруг так стало? Т.е. Task.Run - запустит задачу асинхронно?
Безграничная наивность. Кто-ж будет жертвовать собственным гешефтом в угоду какой-то там эффективности?
Пока существует распил и откат никакие суперкомпьютеры не помогут плановой экономике быть эффективнее рыночной.
Ни разу не упомянуть в контексте TPL про Parallel.ForEach и Parallel.For - это сильно. Даже не уровень джуниора, а ближе к студенту-стажеру.
Про всякие PLINQ и DataFlow вобще молчу...
Чувствуется рука ведущих экспертов с курсов. Мощь.
Решил попробовать локальную лайт версию. Она весьма порадовала:
Скрытый текст
Вобще выглядит так, что в списке достижений не хватает пункта:
- Создал собственную ОС с нескучными обоями
Тимлид должность, в том числе административная, где управленческие навыки и навыки работы с людьми выходят на первое место. Откуда они у 17 летнего юноши, который даже старостой в группе универа не побывал, не говоря о большем.
Да даже если бы у него в 17 лет был красный диплом МГУ - все равно на должность тимлида он не тянул, но возможно, в таком случае, вполне неплохо бы смотрелся на должности техлида.
Капитализм же. С ОЕМ лицензий им в целом неплохая копеечка падает, зачем от нее отказываться?
Обиженный смузихлеб детектед хДД
Все в курсе что виртуализация данных давно есть и в реакте и в вуе и даже в ангуляре (ужас-ужас что делается). Но некоторые фронтендщики настолько зациклены в своем манямирке, что в принципе не способны понять весь юмор происходящего...
О, js-программисты таки изобрели виртуализацию. Not bad, not bad...
Как люди без DI и Channel<T> мучаются-то...
И прямо сегодня же выходит новый биос поднимающий TDP до 105 ватт на младших моделях. Имхо время обновить статью.
Выглядит все плюс-минус симпатично. Но это же юбисофт - они даже шахматы способны превратить в донатную помойку обмазанную повесточкой...
Пока не появится полноценный AGI программистам ничего не грозит. Причина крайне проста и банальна - проблема решенная на 99% не является решенной.