примерно 10 сек. В цикле создается n задач, каждая из которых завершается через 10 сек. Поэтому весь код завершится за 10сек+время создания n объектов и помещение n значений в очередь таймера.
Microsoft вложил в развитие асинхронного рантайма и сокращение аллокаций 10млн человеко-часов. Я думаю в сумме как половина остальных языков из теста.
продвинутый ответ:
Код на C# из статьи вообще не порождает потоков и не использует пул. Delay порождает объект с одним полем, а один поток таймера (один на весь процесс) меняет значение поля через 10 сек и запускает асинхронное продолжение в конце.
по сути это вырожденный случай, потому что если бы была хоть какая-то реальная работа, то результаты забегов были бы совсем другие.
с другой стороны асинхронность в современном мире это не про параллельность вычислений, а про параллельность ожидания. И c#/dotnet под это очень хорошо заточен.
это не обыденная тема, это мнение категорически непрофессионального человека, которое противоречит не только профессиональной этике, но и зачастую банальным принципам вежливого общения.
Причем это мнение подано как какое-то важное и нужное для других.
а этот пост - неуклюжая попытка заигрывать с аудиторией с целью оправдаться за свой непрофессионализм или наоборот «укрепить» свои позиции.
хорошо что замисуовали, надеюсь карму в минус собьют. ИМХО такие «специалисты» на Хабре не нужны
Конечно же это не так. Если мне любой человек будет так писать, то я сразу же попрошу своего или его руководителя исключить этого человека из общения со мной.
это в принципе нормально - отказываться работать с тем, с кем ты не хочешь работать.
Во-первых для начала наверное стоит прочитать Ильяхова про его правила деловой переписки.
Во-вторых если ты пишешь людям, а тебя игнорят, то это проблемы у тебя, а не у них. Если твоя работа заключается в общении с людьми, то твоя первая задача, чтобы они всегда были рады когда ты им звонишь и пишешь.
И самые лучшие способы добиться того чтобы люди были тебе не рады:
Звонить или кидать встречи без предупреждения или согласования
К сожалению не найду ссылку на исследование, но суть такова:
Первое впечатление, которое интервьюер формирует за 10-15 минут (иногда больше, если кандидат рассказывает о себе общими словами), в 8 из 10 случаев оказывается верным. То есть мнение интервьювера брать-набрать, формируемое в первой четверти собеседования в 8 из 10 случаев не меняется в конце. Все описанное в статье в итоге даст не более 20% уверенности в решении.
В другом исследовании видел, что сама по себе точность угадывания продуктивности и длительности работы будущего сотрудника во время собеседования крайне мала.
Стоит оно того - решать вам.
Я последнее время склоняюсь к мысли, что техническое интервью, если оно не формализовано, это просто "позадавать вопросы, чтобы выяснить уровень владения технологиями, которые придется использовать". И это занимает ту самую четверть времени.
А остальные три четверти вы продаете свою вакансию\команду\компанию кандидату. Об этом забывать не стоит.
Если уже есть какая-то база, то даже не стоит вопрос о выборе. Если конкретной базы нет (а её чаще всего нет), то postgres. MySQL тупо слабее и требует лицензирования для коммерческого использования.
Алан Кей придумал не само ООП, он ввел термин ООП для парадигмы Smalltalk (наиболее похожий представитель из сегодняшних мейнтрим языков - Python) уже после появления соответствующих концепций в других языках.
Само ООП как мы его видим в большинстве статически типизированных языков придумали в Simula, а основным популяризатором стал Страустрп, который написал свой дисер на Simula и перенес его концепции на C, создав C++.
Натягиваете сову на глобус. Тимлид это не "менеджер", "менеджер" это примерно на два уровня выше. Тимлид решает очень частную задачу - как сделать так, чтобы все члены команды "гребли" в одну сторону с максимальной эффективностью.
ни во сколько. если вам прделагают как ИП заключаться, то договаривайтесь или на высокую почасовую ставку, ну уровне фриланс бирж, или на гонорар за фиксированный объем
В обоих случаях это и более честно и более правильно с точки зрения закона.
примерно 10 сек. В цикле создается n задач, каждая из которых завершается через 10 сек. Поэтому весь код завершится за 10сек+время создания n объектов и помещение n значений в очередь таймера.
Банальный ответ:
Microsoft вложил в развитие асинхронного рантайма и сокращение аллокаций 10млн человеко-часов. Я думаю в сумме как половина остальных языков из теста.
продвинутый ответ:
Код на C# из статьи вообще не порождает потоков и не использует пул. Delay порождает объект с одним полем, а один поток таймера (один на весь процесс) меняет значение поля через 10 сек и запускает асинхронное продолжение в конце.
по сути это вырожденный случай, потому что если бы была хоть какая-то реальная работа, то результаты забегов были бы совсем другие.
с другой стороны асинхронность в современном мире это не про параллельность вычислений, а про параллельность ожидания. И c#/dotnet под это очень хорошо заточен.
это не обыденная тема, это мнение категорически непрофессионального человека, которое противоречит не только профессиональной этике, но и зачастую банальным принципам вежливого общения.
Причем это мнение подано как какое-то важное и нужное для других.
а этот пост - неуклюжая попытка заигрывать с аудиторией с целью оправдаться за свой непрофессионализм или наоборот «укрепить» свои позиции.
хорошо что замисуовали, надеюсь карму в минус собьют. ИМХО такие «специалисты» на Хабре не нужны
джун аналитик по-любому не единственный в команде, а единственный аналитик и и тем более овнер будет иметь более развитые навыки общения.
Конечно же это не так. Если мне любой человек будет так писать, то я сразу же попрошу своего или его руководителя исключить этого человека из общения со мной.
это в принципе нормально - отказываться работать с тем, с кем ты не хочешь работать.
А должно быть грустно. Вы не осознаете проблему, которую создаете себе и другим.
Продолжайте в том же духе и скоро заметите как все «срочные вопросы», от которых что-то зависит, пойдут мимо вас.
Так он потом скажет что не видел эти протокол и вообще не говорил такого.
Почему же?
Во-первых для начала наверное стоит прочитать Ильяхова про его правила деловой переписки.
Во-вторых если ты пишешь людям, а тебя игнорят, то это проблемы у тебя, а не у них. Если твоя работа заключается в общении с людьми, то твоя первая задача, чтобы они всегда были рады когда ты им звонишь и пишешь.
И самые лучшие способы добиться того чтобы люди были тебе не рады:
Звонить или кидать встречи без предупреждения или согласования
Писать письма крупным или красным шрифтом
Везде добавлять руководителя в переписку
Верно
Гори в аду
Гори в аду
Гори в аду
Это как вообще? кто и или что кого должно ограничить?
А зачем протокол без ответственных? Это не просто стандартная практика, а это единственное осмысленное действие в протоколе
Очень сомневаюсь что от количества "пожалуйста" хоть что-то зависит
Игнорят письма, потому что людям есть чем заняться вместо ответов на тупые вопросы.
Посоветую бросить работы в ИТ, поискать гденить в другом месте.
К сожалению не найду ссылку на исследование, но суть такова:
Первое впечатление, которое интервьюер формирует за 10-15 минут (иногда больше, если кандидат рассказывает о себе общими словами), в 8 из 10 случаев оказывается верным. То есть мнение интервьювера брать-набрать, формируемое в первой четверти собеседования в 8 из 10 случаев не меняется в конце. Все описанное в статье в итоге даст не более 20% уверенности в решении.
В другом исследовании видел, что сама по себе точность угадывания продуктивности и длительности работы будущего сотрудника во время собеседования крайне мала.
Стоит оно того - решать вам.
Я последнее время склоняюсь к мысли, что техническое интервью, если оно не формализовано, это просто "позадавать вопросы, чтобы выяснить уровень владения технологиями, которые придется использовать". И это занимает ту самую четверть времени.
А остальные три четверти вы продаете свою вакансию\команду\компанию кандидату. Об этом забывать не стоит.
В РФ сейчас негде взять "подороже и с саппортом", поэтому Postgres.
Раньше в банках везде был оракл, а кто поменьше - MS SQL, а теперь везде пострегс, или будет постгрес в ближайшее время.
Если уже есть какая-то база, то даже не стоит вопрос о выборе. Если конкретной базы нет (а её чаще всего нет), то postgres. MySQL тупо слабее и требует лицензирования для коммерческого использования.
Разве есть сейчас альтернатива postgres для любых транзакционных данных?
я первые 5 мин серьёзно читал
TS изначально, а JS примерно в 2017 получил классы и наследование, как в других C-подобных языках
Алан Кей придумал не само ООП, он ввел термин ООП для парадигмы Smalltalk (наиболее похожий представитель из сегодняшних мейнтрим языков - Python) уже после появления соответствующих концепций в других языках.
Само ООП как мы его видим в большинстве статически типизированных языков придумали в Simula, а основным популяризатором стал Страустрп, который написал свой дисер на Simula и перенес его концепции на C, создав C++.
А сколько людей у вас в подчинении?
В понимании текущего рынка труда тимлид в ит - это руководитель небольшой команды, без функций управления бюджетом и стратегией.
Ну когда мы говорим об одном человеке, то для компании это не проблема. А если это команда, то уже серьезные затраты.
Натягиваете сову на глобус. Тимлид это не "менеджер", "менеджер" это примерно на два уровня выше. Тимлид решает очень частную задачу - как сделать так, чтобы все члены команды "гребли" в одну сторону с максимальной эффективностью.
ни во сколько. если вам прделагают как ИП заключаться, то договаривайтесь или на высокую почасовую ставку, ну уровне фриланс бирж, или на гонорар за фиксированный объем
В обоих случаях это и более честно и более правильно с точки зрения закона.