Относительно Sprache, query expression как раз удобен из-за необходимости "выпрямления" запроса
Parser<string> identifier =
from leading in Parse.WhiteSpace.Many()
from first in Parse.Letter.Once().Text()
from rest in Parse.LetterOrDigit.Many().Text()
from trailing in Parse.WhiteSpace.Many()
select first + rest;
var id = identifier.Parse(" abc123 ");
Assert.AreEqual("abc123", id);
И вот он, наш идеальный кандидат, заходит в наш отдельный кабинет, без окон, садиться за рабочее место и спрашивает «Простите, извините, а где у вас тут кофемашина?». А мы честно отвечаем «Сорри, кофемашины нет».
Т.е. у вас откровенно скотские условия:
Кабинет без окон
Судя по фразе «садится за рабочее место», IOS разработчику вместо профессионального устройства, а именно mac book, выдали комп с медиацентром mac mini
И как последняя капля: нет кофемашины
К слову, согласен с автором по всем пунктам, кроме раздела «про плюшки».
Я считаю, что отсутвие классческих для IT бенефитов, как то кофе машина, турник, зона отдыха и проч. является показателем низкой квалификации менежмента. Для компании стоимость этих «плюшек» ничтожна в сравнении с тем, как хорошо это улучшает лояльность сотрудников. Не случайно все крупные IT компании делают на бенефиты особый фокус — это просто выгодно.
Если же для Вас конкретно это ничего не значит, то это только Ваша особенность, не стоит ее экстрополировать. Возможно, у Вас стокгольмский синдром.
Кстати, а у вас какие стулья? Нормальные, или самые дешевые? Это тоже крутой показатель: масса IT компаний готовы платить по 200к в месяц программистам, но не готовы постратить один раз 10к на покупку стула. В итоге падает продуктивность, так как неудобно сидеть и эти стулья постоянно ломаются.
Просто если у Вас в организации так плохо с бенефитами, стоит уточинть, какое образование у вашего менежмента… вполне возможно, что точно «не менеджерское». А значит Ваш директор не сильно квалифицированнее в области управления, чем приходящие к вам джуны. Навык давания взяток и сидения в сауне с нужными людьми не счет, это специфика РФ:)
Коротко: нельзя просто так начать давать виртуальные монетки и ожидать что человек будет делать ради них то, что ему не нравится. Это очень сложный инструмент, который не так просто заставить работать.
Да, классическая система плохо роботает, но она работет. Все экспериментальные системы требуют очень внимательного анализа результатов, на достаточно большой выборке различных учеников. И анализ должен быть максимально объективным.
Более того, если говорить об образовании, то система оценивания (пятерки, четверки и проч.) как раз является примером геймификации.
> переход с версии на версию ломают проекты
Мне кажется, в плане Unity не стоит вообще обновляться на на LTS релизы. Разработчики пилят сейчас очень много новых (и реально крутых) фич, что с учетом размеры команды, не позволяет им с первого раза выкатывать нормальную версию. В принипе, похожая ситуация была в свое время с докером, когда x.0 версией нельзя было пользоваться.
> Парадигма поиска объектов по их текстовому имени
А кто требует этим пользоваться, можно же искать по тегу? В unity есть еще масса проблемных вещей, которые не стоит юзать.
> Проваливание гейм объектов через стандартные коллайдеры
А можно линку? У меня были похожие проблемы, но только если я двигал что-то в Update, а не в FixedUpdate. Но похоже тут другая проблема…
Проверяли как то холодный старт в AWS… нода всех уделал в плане холодного старта, а .Net после прогрева. Но это было год назад, сейчас может поменялось.
Так же была одна задача, когда генерили тонну инстансов на пару секунд. И там JIT был оченьвреден и пришлось использоват другой подход.
И вот тут возникает интересная ситуация: в соседнем топике про «Scala крута, но большой бинарь. Вот приходится писать на go» мой вопрос «а почему бы не посмотреть на C#» заминусовали. habr.com/en/post/520114/#comment_22130682
Возникает ощущение, что большинство не .net разработчиков предпочитает не задумываться о существовании C#/.Net. И как результат, страдают. Невежество оно такое… поражает в первую очередь невежду.
Действительно странная логика автора: c чего это JIT может быть медленее AOT? Есть же, в таком случае, возможность оптимизации под конкретное железо, но котором выполняется код.
А вот где действительно есть просадка, так это во времени запуска. Но тут лучше не go выбирать, а node.js, так как холодный старт объективно выше в интерпретируемых языках.
С другой стороны… а в каких случаях вам нужен именно быстрых холодный старт?
Зарплаты на 10% ниже чем у Java разработчиков сравнимой компетенции
До сих пор есть «особенные» разработчики, считающие что C# это только Windows или только формочки
Есть несколько языковых конструкции (например поддержка динамической типизации вместе со статической) которые не нужны (хотя тот же dynamic замечательно подходит для прототипирования)
Не возникают так часто проблемы с heap при работе с большим объемом данных (так как есть отдельный дефрагментируемый heap для больших объектов), но вот конфигурируемости GC, что есть в java, увы нет. Как и внятных альтернативам дефоллтному GC
AOP есть, но не популярен
Есть только один внятный фреймворк для мутационного тестирования
Интерация со Apache Spark тольк очерез API (как сделано в python), т.е. нет возможность вклинивать свой код в ноды, как можно в JVM ориентированных языках
ML в зачаточном состоянии. Но это если мы не говорим о SAAS. В плане интеграции с ML SAAS решений все ок (а это и нужно в 90% случаев :) )
Кросс платформ для мобилок очень мощный (так как есть прямой доступ к нативным API), то требует высокой квалификации (так как есть прямой доступ к нативным API)
Если говорить о Unity, то проблема не в «глюках», а в банальных вещах: GC (в Unity он «свой») и комплируемости языка (очень бесит что, по сравнению с Godot, необходимо перезапускать проект (и перепроходит уровень) ради написания одной строчки кода)
.wasm фреймворк blazor неплох, но пока недостаточно mature
Интеграция с anaconda есть… но этого недостаточно
Т.е. если у вас есть задачи, которые я описал выше (ML, Data Science, Spark, Big Data), то C# тут действительно не очень хорошо подходит
> Почему нет ничего про его четкую заточенность на Виндовс?
Microsoft уже сами депрецировали не cross platform версию .Net. Сейчас большинство .Net приложений или уже на linux, или переходят, так как это отличный способ экономии.
Это, кстати, крайне удобно для разработчиков. В то время как джависты с трудом «продают» переход со старых версий Spring, .Net разработчикам достаточно показать как дорого стоит виндовый сервер и… рефакторинг продан:)
> Десктоп приложения на нем писать можно только под мелкомягких
А разве десктоп кому-то сейчас нужен? Сейчас разработка это или бек, или веб фронт, или мобилки, или игры.
>… глючном юнити
А можно рассказать про глючность юнити? А то у читателей может возникнуть ложное ощущение, что в Unreal Engine, как будто, глюков меньше.
Еще задолго до C#8 я перестал использвоать нулы в своем коде и, как результат, практически никогда не встречал NRE, кроме 100500 случаев интеграции с кодом других людей :(. Основная же проблема в том, что раньше у нас был только NotNull от JetBrains.
А теперь появилась возможность явно указать, может быть в коде нулл или нет. Но если человек «явно врет» в своем коде, передавая null под видом not null, это не проблема языка, а проблема программиста-врунишки.
Только вот WinForms/WPF, которые с недавнего времени работают на Net Core, поддерживают только Windows. Просто потому что «формочные» фреймворки сильно привязаны к развесистому WinAPI.
Microsoft не Apple, они не будут поступать как м… ки и ломать обратную совместимость важного для профессионалов софта
Интересно почему автор не рассматривает .Net стек:
Производительность лучше чем в Java и Go
Собранный docker image сравним по размеру с Go
Синтаксис не менее богатый чем Scala при куда более удобном тулинге: чего стоят синтаксические анализаторы, поставляемые с библиотеками и помогающие работать с конкретно этими библиотеками
Из основных фреймворков было вычищено все легаси. По сути произошел глобальный рефакторинг всей экосистемы 4 года назад
Я не пытаюсь рекламировать C#, просто интересно, почему он не входит в «поле зрения» при принятии решения.
Похоже, малыш не может отличить прототип от законченного продукта. Не ругайте его, мы все проходим через такой этап, когда нас просят проэстимировать задачу.
Ужасно опасная статья, так как некоторые «советы» могут принести очень много вреда:
1. Наводите порядок в коде, с которым работаете
— Практика показала, что после парочки «мини изменений» git blame и прочие способы понять в какой момент была написана эта строча, а значит понять связь с таской, перестают работать.
4. Планируйте работу над кодом
— Самый ужасны из советов. Дело в том, что более менее сложные задачи достаточно тяжело распланировать заранее в голове. Как результат — ступор, когда ты не можешь написать первую строчку кода. Гораздо более надежное решение — итеративный инкрементальный подход, когда мы сначала реализуем задачу, а потом обязательно полируем-рефакторим. И да, я специально не говорю про TDD, дабы не разводить флейм.
5. Документируйте свои проекты
— А вот это, определенно, полезно. Только есть проблема — написать работающую безвредную документацию не менее сложно чем написать работающий безвредный код. Одной привычке недостаточно, необходимо умение и опыт
В начале удивило, что английский не так сильно нужен, но потом обратил внимание на город. Возможно, я не прав, но похоже в Москве куда больше организаций, работающих на внутренний рынок, нежели за МКАД. В том же СПБ, ИМХО, наличие английского гораздо важнее. Поправьте меня, если я не прав
Мне очень понравился комментарий «директора по разработке одной аутсорс компании». Особенно пункт «На hh десятки откликов».
Как человек, работающий в одной аутсорс компании совершенно не понимаю, как можно так разбрасываться кадрами: нормальных разрабов уровня миддл+ днем с огнем не найти. Я про тимлидов вообще молчу: за последние 4 года видел только парочку ребят «с улицы», которые бы и программировать умели, и soft skills обладали, и управленческие навыки развивали. Из десятка откликов треть в тимлиды прыгнула из джуновских шортиков, вторая треть канбан от UP не отличит, а у последние по стилю управления не отошли дальше дедов-сержантов.
В итоге, «выжимальщики соков» как раз собирают с рынка слабых кандидатов. Как результат, квалификация команд — ни к черту. К сожалению, хороший продажник может и кусок фекалий продать под видом сеньера. И очень печально, что из-за таких недальновидных и низкоквалифицированных менеджеров рушатся неплохие компании и очерняются другие аутсорсеры.
Так что, я так думаю, стоит обнародовать имя данного директора аутсорс компании. Вполне возможно, эта фирмочка уже на ладан дышит.
Возможно я не прав, но я заметил интересную корреляцию:
1. «Устойчивые к токсичности» коллеги неплохо мотивируются подтруниванием, штрафами и проч. Но если их «подотпустить», то они быстро скатываются. Причина, на мой взгляд, в банальной самоуверенности. Если самоуверенному программисту скажут, что его код «можно улучшить», то он даже не обратит на это внимание. Поэтому на таких ребят и действуют меры, описанные Вами.
2. «Феечки» же, после штрафов, очень быстро начинают стрессовать, а как известно, стресс негативно влияет на когнитивные возможности. Как результат, вместо мотивированного сотрудника мы получаем туповатого. Причина, как правило, в некоторой неуверенности в себе. Человек может быть очень опытным программистом, но если он сам сомневается в том, на сколько он хороший разработчик, то грубая критика его просто уничтожает. Что до мотивации, в рабочей атмосфере неуверенность это лучший стимул к развитию, так как сотрудник пытается быть лучше.
А вот когда мы сталкиваемся с самоуверенными феечками, то тогда «тушите воду». Встречал пару раз такие девиации. К сожалению, такие ребята сами являются как жертвами токсичности, так и источниками оной. ИМХО, единственное что можно с ними сделать, давать изолированные задачи и делегировать небольшие области + регулярные (не случайный) контроль. Из плюсов, обычно это хорошие специалисты, все таки неуверенность дает свои положительные плоды: люди много читают и активно развиваются.
Хорошее замечание.
Относительно Sprache, query expression как раз удобен из-за необходимости "выпрямления" запроса
Т.е. у вас откровенно скотские условия:
К слову, согласен с автором по всем пунктам, кроме раздела «про плюшки».
Я считаю, что отсутвие классческих для IT бенефитов, как то кофе машина, турник, зона отдыха и проч. является показателем низкой квалификации менежмента. Для компании стоимость этих «плюшек» ничтожна в сравнении с тем, как хорошо это улучшает лояльность сотрудников. Не случайно все крупные IT компании делают на бенефиты особый фокус — это просто выгодно.
Если же для Вас конкретно это ничего не значит, то это только Ваша особенность, не стоит ее экстрополировать. Возможно, у Вас стокгольмский синдром.
Кстати, а у вас какие стулья? Нормальные, или самые дешевые? Это тоже крутой показатель: масса IT компаний готовы платить по 200к в месяц программистам, но не готовы постратить один раз 10к на покупку стула. В итоге падает продуктивность, так как неудобно сидеть и эти стулья постоянно ломаются.
Просто если у Вас в организации так плохо с бенефитами, стоит уточинть, какое образование у вашего менежмента… вполне возможно, что точно «не менеджерское». А значит Ваш директор не сильно квалифицированнее в области управления, чем приходящие к вам джуны. Навык давания взяток и сидения в сауне с нужными людьми не счет, это специфика РФ:)
Коротко: нельзя просто так начать давать виртуальные монетки и ожидать что человек будет делать ради них то, что ему не нравится. Это очень сложный инструмент, который не так просто заставить работать.
Да, классическая система плохо роботает, но она работет. Все экспериментальные системы требуют очень внимательного анализа результатов, на достаточно большой выборке различных учеников. И анализ должен быть максимально объективным.
Более того, если говорить об образовании, то система оценивания (пятерки, четверки и проч.) как раз является примером геймификации.
Мне кажется, в плане Unity не стоит вообще обновляться на на LTS релизы. Разработчики пилят сейчас очень много новых (и реально крутых) фич, что с учетом размеры команды, не позволяет им с первого раза выкатывать нормальную версию. В принипе, похожая ситуация была в свое время с докером, когда x.0 версией нельзя было пользоваться.
> Парадигма поиска объектов по их текстовому имени
А кто требует этим пользоваться, можно же искать по тегу? В unity есть еще масса проблемных вещей, которые не стоит юзать.
> Проваливание гейм объектов через стандартные коллайдеры
А можно линку? У меня были похожие проблемы, но только если я двигал что-то в Update, а не в FixedUpdate. Но похоже тут другая проблема…
Так же была одна задача, когда генерили тонну инстансов на пару секунд. И там JIT был оченьвреден и пришлось использоват другой подход.
habr.com/en/post/520114/#comment_22130682
Возникает ощущение, что большинство не .net разработчиков предпочитает не задумываться о существовании C#/.Net. И как результат, страдают. Невежество оно такое… поражает в первую очередь невежду.
А вот где действительно есть просадка, так это во времени запуска. Но тут лучше не go выбирать, а node.js, так как холодный старт объективно выше в интерпретируемых языках.
С другой стороны… а в каких случаях вам нужен именно быстрых холодный старт?
Т.е. если у вас есть задачи, которые я описал выше (ML, Data Science, Spark, Big Data), то C# тут действительно не очень хорошо подходит
Microsoft уже сами депрецировали не cross platform версию .Net. Сейчас большинство .Net приложений или уже на linux, или переходят, так как это отличный способ экономии.
Это, кстати, крайне удобно для разработчиков. В то время как джависты с трудом «продают» переход со старых версий Spring, .Net разработчикам достаточно показать как дорого стоит виндовый сервер и… рефакторинг продан:)
> Десктоп приложения на нем писать можно только под мелкомягких
А разве десктоп кому-то сейчас нужен? Сейчас разработка это или бек, или веб фронт, или мобилки, или игры.
>… глючном юнити
А можно рассказать про глючность юнити? А то у читателей может возникнуть ложное ощущение, что в Unreal Engine, как будто, глюков меньше.
А теперь появилась возможность явно указать, может быть в коде нулл или нет. Но если человек «явно врет» в своем коде, передавая null под видом not null, это не проблема языка, а проблема программиста-врунишки.
Microsoft не Apple, они не будут поступать как м… ки и ломать обратную совместимость важного для профессионалов софта
Я не пытаюсь рекламировать C#, просто интересно, почему он не входит в «поле зрения» при принятии решения.
1. Наводите порядок в коде, с которым работаете
— Практика показала, что после парочки «мини изменений» git blame и прочие способы понять в какой момент была написана эта строча, а значит понять связь с таской, перестают работать.
4. Планируйте работу над кодом
— Самый ужасны из советов. Дело в том, что более менее сложные задачи достаточно тяжело распланировать заранее в голове. Как результат — ступор, когда ты не можешь написать первую строчку кода. Гораздо более надежное решение — итеративный инкрементальный подход, когда мы сначала реализуем задачу, а потом обязательно полируем-рефакторим. И да, я специально не говорю про TDD, дабы не разводить флейм.
5. Документируйте свои проекты
— А вот это, определенно, полезно. Только есть проблема — написать работающую безвредную документацию не менее сложно чем написать работающий безвредный код. Одной привычке недостаточно, необходимо умение и опыт
Как человек, работающий в одной аутсорс компании совершенно не понимаю, как можно так разбрасываться кадрами: нормальных разрабов уровня миддл+ днем с огнем не найти. Я про тимлидов вообще молчу: за последние 4 года видел только парочку ребят «с улицы», которые бы и программировать умели, и soft skills обладали, и управленческие навыки развивали. Из десятка откликов треть в тимлиды прыгнула из джуновских шортиков, вторая треть канбан от UP не отличит, а у последние по стилю управления не отошли дальше дедов-сержантов.
В итоге, «выжимальщики соков» как раз собирают с рынка слабых кандидатов. Как результат, квалификация команд — ни к черту. К сожалению, хороший продажник может и кусок фекалий продать под видом сеньера. И очень печально, что из-за таких недальновидных и низкоквалифицированных менеджеров рушатся неплохие компании и очерняются другие аутсорсеры.
Так что, я так думаю, стоит обнародовать имя данного директора аутсорс компании. Вполне возможно, эта фирмочка уже на ладан дышит.
1. «Устойчивые к токсичности» коллеги неплохо мотивируются подтруниванием, штрафами и проч. Но если их «подотпустить», то они быстро скатываются. Причина, на мой взгляд, в банальной самоуверенности. Если самоуверенному программисту скажут, что его код «можно улучшить», то он даже не обратит на это внимание. Поэтому на таких ребят и действуют меры, описанные Вами.
2. «Феечки» же, после штрафов, очень быстро начинают стрессовать, а как известно, стресс негативно влияет на когнитивные возможности. Как результат, вместо мотивированного сотрудника мы получаем туповатого. Причина, как правило, в некоторой неуверенности в себе. Человек может быть очень опытным программистом, но если он сам сомневается в том, на сколько он хороший разработчик, то грубая критика его просто уничтожает. Что до мотивации, в рабочей атмосфере неуверенность это лучший стимул к развитию, так как сотрудник пытается быть лучше.
А вот когда мы сталкиваемся с самоуверенными феечками, то тогда «тушите воду». Встречал пару раз такие девиации. К сожалению, такие ребята сами являются как жертвами токсичности, так и источниками оной. ИМХО, единственное что можно с ними сделать, давать изолированные задачи и делегировать небольшие области + регулярные (не случайный) контроль. Из плюсов, обычно это хорошие специалисты, все таки неуверенность дает свои положительные плоды: люди много читают и активно развиваются.