Интересно какие причины попуждают сидеть на Windows 7? Ладно ещё Win8 была спорной, и 11 жрёт немного больше ресурсов и панель задач не передвинуть на лувую сторону, но почему не Windows 10?
В чём тут проблема? Работа «сделана» означает что она принята потребителем этой работы, в случае производства это другой отдел. Кроме потребителей есть такой древний отдел под названием «Контроль качества», контролирует работу на соответствие заданным параметрам ещё до приёмки её заказчиком.
«КПИ» и прочие нововведения можно оставить высоко эффективным менеджерам. Есть работа измеряемая, к примеру количество единиц продукции в единицу времени, и не измеряемая – любая разработка. Но некоторым эффективным менеджерам очень хочется измерить и такую работу – отсюда появляются KPI на количество строчек кода / текста / исследований, закрытые задач и прочие удивительные показатели.
Доверие же строиться между руководителями – именно они договариваются о сроках и ресурсах на выполнение работы, своего рода внутренняя купля-продажа и придерживаются принципа «вассал моего вассала, не мой вассал». В такой системе руководитель озабочен только своим отделом, а вышестоящий менеджер «не лезет» в работу отдела, то есть занимаются только Эпиками, а не Таксками, которыми владеет руководитель отдела.
Откуда вы взяли что Скрам живёт не только в АйТи разработке? Он отлично себя чувствует и в разработке реального продукта. Но я не спорю, российская промышленность далека от передовых технологий…
Кто-то очень умный сказал: «Чем больше отчётности, тем меньше доверия».
Несколько мыслей по этой теме: Подобный учёт рабочего времени порой «сводит на нет» внутри командное взаимодействие между коллегами – каждый озабочен об отчёте за потраченное время на помощь друг другу.
Оценка трудозатрат на разработку (хоть ПО, хоть машина) совершенно отличается от оценки трудозатрат на производство уже разработанного изделия.
На некоторых «заводах» всё ещё применяют почасовую слежку за персоналом, потому как уровень доверия находится на ноле. На некоторых «АйТи-галерах» такая форма слежки является обязательной, возможно, потому как нужно что-то продавать клиентам и из-за отсутствия уверенности у руководства в собственных силах.
У меня и у многих моих коллег такая система отчётности вызывает ощущения взаимодействия с работодателем по типу «раб – надзиратель».
PS: Довелось мне работать в одной компании с разработкой реального осязаемого продукта. Как-то раз сменилось начальство (не буду уточнять которое из них было более эффективным), а новое ввело правильно повременного отчёта за день, формата: задача – потраченное время. Не малая часть персонала «разбежалась» уже в течение нескольких месяцев после такого нововведения. Хотя одна очень сообразительная сотрудница уже через пару недель навострилась писать отчёта на всю неделю вперёд по понедельникам, но всё равно ушла через полгода. Я же после введения такого отчёта полностью перестал заниматься работой в нерабочее время, а занимался я тогда маркетингом. Поначалу писал отчёт по полчаса-час в день, а через месяц так же приспособился и навострился ваять их за 10 минут.
То есть, в мире полно уникомов способных освоить язык и полноценный фреймворк "условно" за испытательный срок? Я очень сомневаюсь, что МААНГ собрал 100000 людей способных на такое быстрое обучение.
Я за свою небольшую практику уже насмотрелся на "велосипеды" в кодовых базах очень обеспеченных копаний. Порой было стойкое ощущение, что разработчики начали работать с .NET только на этом проекте. При этом, чтобы писать высокопроизводительный код нужно знать особенности языка и тонкости фреймворка.
Конечно же я не отрицаю возможность переда между Java Spring - C# .NET - Kotlin - Dart, эти языки очень близки. Программисты этим занимаются уже давно и переходят вполне успешно, но достичь тот же уровень сеньорности потребуется явно не пара месяцев обучения.
То есть что бы устроиться на работу по профилю нужно освоить технологию не по профилю?
К примеру, занимаюсь я .NET и ничего кроме .NET (и порой TS/JS ни нужно), но что бы устроиться на работу, вместо повышения навыков в основной специализации, нужно распыляться на Питон, Го или ещё что-нить далёкое…
Это только мне данная ситуация кажется кринжовой? PS: к автору никаких претензий не имею, а вот ситуация с наймом очень неоднозначная.
Ну да, "бизнес" возможности Тимсов порой превалирует. Хотя Телеграмм также может собрать 10 человек в группе на звонок и пошарить экран, а вот записью экрана не интересовался ?
После двух лет работы с MS Teams я вообще не понимаю, как можно выбрать насколько забагованный мессенджер для повседневной работы. Возможно новая версия (сейчас в публичной Бете) исправить явные косяки и Тимсы начнут стабильно работает без сбоев, но на данный момент это ПО сборник жуков разных мастей.
Столько много тирад над "Зачем нужен брокер сообщений", но всего пара постов про асинхронные операции, что по моему скромному мнению является основным преимуществом перед синхронными REST и gRPC.
Positional properties are immutable in a record class and a readonly record struct. They're mutable in a record struct.
Как по мне, дак получилась каша из ключевых слов иммутабельности. Для супер сеньоров такие конструкции вполне понятны, а вот новичков в языке могут сильно запутать.
Ну да, для MAUI есть даже специальный пакет позволяющий писать представление через код, но пакет этот community-driven и официально не поддерживается MS.
Хм, но бесплатная версия VS Community 2022 так же поддерживает MAUI. Хотя я использую Rider по подписочной модели и подобных сложностей не возникает, разве что лаг с поддержкой нововведений в .NET примерно в месяц.
Собственно, у нас не было большого выбора, поскольку проект реализуется под Windows, и большая часть кода выполнена на C#.
Не знаю, когда запускался ваш проект, но если в прошлом году, то почему не рассматривали MAUI?
PS: По моему мнению для джуна и мидла (не так давно пришедшего в айти, и пропустившего всякие там XML-конфиги и подобное), вот этот XAML выглядит как Китайская грамота, поэтому Flutter в купе с поставляемым из коробки UI-kit, без XAMLа и предлагающей строить представление через код, является куда более доступной технологией нежели чем, новомодный MAUI или тот же WPF, даже при всей моей любви к C# с .NET и отторжению React.
Разве Keyd Services в .NET 8 не решают эту проблему?
На DotNext есть отличная лекция по этой теме. Станислав Сидристый — lock(_sync): иллюзия идеального выбора
Можно по-подробнее как сверстать резюме для ATS систем: "Это очень важно, чтобы резюме выделялось, а на западе еще и проходило ATS системы"?
Интересно какие причины попуждают сидеть на Windows 7?
Ладно ещё Win8 была спорной, и 11 жрёт немного больше ресурсов и панель задач не передвинуть на лувую сторону, но почему не Windows 10?
>Смотреть по сделанной работе
В чём тут проблема? Работа «сделана» означает что она принята потребителем этой работы, в случае производства это другой отдел. Кроме потребителей есть такой древний отдел под названием «Контроль качества», контролирует работу на соответствие заданным параметрам ещё до приёмки её заказчиком.
«КПИ» и прочие нововведения можно оставить высоко эффективным менеджерам. Есть работа измеряемая, к примеру количество единиц продукции в единицу времени, и не измеряемая – любая разработка. Но некоторым эффективным менеджерам очень хочется измерить и такую работу – отсюда появляются KPI на количество строчек кода / текста / исследований, закрытые задач и прочие удивительные показатели.
Доверие же строиться между руководителями – именно они договариваются о сроках и ресурсах на выполнение работы, своего рода внутренняя купля-продажа и придерживаются принципа «вассал моего вассала, не мой вассал». В такой системе руководитель озабочен только своим отделом, а вышестоящий менеджер «не лезет» в работу отдела, то есть занимаются только Эпиками, а не Таксками, которыми владеет руководитель отдела.
Откуда вы взяли что Скрам живёт не только в АйТи разработке? Он отлично себя чувствует и в разработке реального продукта. Но я не спорю, российская промышленность далека от передовых технологий…
Кто-то очень умный сказал: «Чем больше отчётности, тем меньше доверия».
Несколько мыслей по этой теме:
Подобный учёт рабочего времени порой «сводит на нет» внутри командное взаимодействие между коллегами – каждый озабочен об отчёте за потраченное время на помощь друг другу.
Оценка трудозатрат на разработку (хоть ПО, хоть машина) совершенно отличается от оценки трудозатрат на производство уже разработанного изделия.
На некоторых «заводах» всё ещё применяют почасовую слежку за персоналом, потому как уровень доверия находится на ноле.
На некоторых «АйТи-галерах» такая форма слежки является обязательной, возможно, потому как нужно что-то продавать клиентам и из-за отсутствия уверенности у руководства в собственных силах.
У меня и у многих моих коллег такая система отчётности вызывает ощущения взаимодействия с работодателем по типу «раб – надзиратель».
PS: Довелось мне работать в одной компании с разработкой реального осязаемого продукта. Как-то раз сменилось начальство (не буду уточнять которое из них было более эффективным), а новое ввело правильно повременного отчёта за день, формата: задача – потраченное время.
Не малая часть персонала «разбежалась» уже в течение нескольких месяцев после такого нововведения. Хотя одна очень сообразительная сотрудница уже через пару недель навострилась писать отчёта на всю неделю вперёд по понедельникам, но всё равно ушла через полгода.
Я же после введения такого отчёта полностью перестал заниматься работой в нерабочее время, а занимался я тогда маркетингом. Поначалу писал отчёт по полчаса-час в день, а через месяц так же приспособился и навострился ваять их за 10 минут.
Необычная статься по .NET для хабра – чаще разбирают очень странные кейсы, которые могут быть сильно упрощены стандартным функционалом .NET.
Почему в методе HttpClientHandler.SendAsync использовали .GetAwaiter().GetResult() вместо нормального await, метод же возвращает Task?
Статья интересная!
Порционный подход очень нравится - позволяет читать такие выжимки в "перерывах на обед".
Определённо продолжайте!
То есть, в мире полно уникомов способных освоить язык и полноценный фреймворк "условно" за испытательный срок? Я очень сомневаюсь, что МААНГ собрал 100000 людей способных на такое быстрое обучение.
Я за свою небольшую практику уже насмотрелся на "велосипеды" в кодовых базах очень обеспеченных копаний. Порой было стойкое ощущение, что разработчики начали работать с .NET только на этом проекте. При этом, чтобы писать высокопроизводительный код нужно знать особенности языка и тонкости фреймворка.
Конечно же я не отрицаю возможность переда между Java Spring - C# .NET - Kotlin - Dart, эти языки очень близки. Программисты этим занимаются уже давно и переходят вполне успешно, но достичь тот же уровень сеньорности потребуется явно не пара месяцев обучения.
То есть что бы устроиться на работу по профилю нужно освоить технологию не по профилю?
К примеру, занимаюсь я .NET и ничего кроме .NET (и порой TS/JS ни нужно), но что бы устроиться на работу, вместо повышения навыков в основной специализации, нужно распыляться на Питон, Го или ещё что-нить далёкое…
Это только мне данная ситуация кажется кринжовой?
PS: к автору никаких претензий не имею, а вот ситуация с наймом очень неоднозначная.
Nullable reference type завезли относительно недавно. Возможно материал готовился по старому С#?
Ну да, "бизнес" возможности Тимсов порой превалирует.
Хотя Телеграмм также может собрать 10 человек в группе на звонок и пошарить экран, а вот записью экрана не интересовался ?
От всего изложенного очень сильно веет "Бизнес молодостью".
Особенно хорошо контрастирует
с недавней статьёй от авитологов, сознательно ограничивающих количество одновременно обслуживаемых клиентов.
После двух лет работы с MS Teams я вообще не понимаю, как можно выбрать насколько забагованный мессенджер для повседневной работы. Возможно новая версия (сейчас в публичной Бете) исправить явные косяки и Тимсы начнут стабильно работает без сбоев, но на данный момент это ПО сборник жуков разных мастей.
Столько много тирад над "Зачем нужен брокер сообщений", но всего пара постов про асинхронные операции, что по моему скромному мнению является основным преимуществом перед синхронными REST и gRPC.
Я полагал, что "хранимые процедуры" уже давно ушли в bad practice и на нормальных проектах логику в базы данных никто перекладывать ни будет.
Кому лень искать:
Как по мне, дак получилась каша из ключевых слов иммутабельности. Для супер сеньоров такие конструкции вполне понятны, а вот новичков в языке могут сильно запутать.
Ну да, для MAUI есть даже специальный пакет позволяющий писать представление через код, но пакет этот community-driven и официально не поддерживается MS.
Хм, но бесплатная версия VS Community 2022 так же поддерживает MAUI.
Хотя я использую Rider по подписочной модели и подобных сложностей не возникает, разве что лаг с поддержкой нововведений в .NET примерно в месяц.
Не знаю, когда запускался ваш проект, но если в прошлом году, то почему не рассматривали MAUI?
PS: По моему мнению для джуна и мидла (не так давно пришедшего в айти, и пропустившего всякие там XML-конфиги и подобное), вот этот XAML выглядит как Китайская грамота, поэтому Flutter в купе с поставляемым из коробки UI-kit, без XAMLа и предлагающей строить представление через код, является куда более доступной технологией нежели чем, новомодный MAUI или тот же WPF, даже при всей моей любви к C# с .NET и отторжению React.