Тоже не с первого раза заметил. По всей видимости речь идет о клиенте:
В одном из своих проектов я выяснил, что открепление сообщения и удаление кнопок под сообщением в одно время «роняет» Telegram Desktop на Windows и Linux.
Почти год назад Windows Terminal уже упрекали в медлительности. Casey Muratori даже набросал прототип терминала, который выдавал тысячи FPS на рендеринге.
В результате Windows Terminal адаптировал новый rendering engine. Интересно, насколько это изменение связано с проблемой, разобранной в статье?
Со всеми этими Mr, Ms, Sir и им подобными обращениями очень легко в современной "толерантной" среде нажить себе проблем. Мало ли как себя оппонент идентифицирует (He, She, They) и обращение с "половым" уклоном легко может спровоцировать если не конфликт, то серьезное недопонимание.
Вот например "женщину" оскорбили на конференции:
I’m leaving the SQL Server community. Since the only reason I had a Twitter account was to be a part of this community I’ll be deleting my account after sending these messages. 1/2
Справедливости ради, на презентации сказали, что докер на новой платформе будет запускать образ с ARM-версией ядра. А это значит, что образ-то может и запустится, но поведение его может отличаться от продуктовой среды, потому что серверная инфраструктура на 99% это x86.
Окей гугл: как пройтись по всем сайтовым коллекциям SharePoint и почистить в них корзину из LINQPad? Как в несколько шагов организовать миграцию для SQL Server по аналогии с dbatools?
Может для программиста и проще накидать скетч на C#, а для администратора проще написать скрипт на повершеле. Тем более, что управление инфраструктурой Microsoft построено вокруг PowerShell.
А зачем строки менять? PowerShell десериализует JSON в объект и достаточно будет поменять свойство нужных полей, а потом сериализовать и отправить ответ:
Люблю и ненавижу PowerShell. С одной стороны позволяет с легкостью автоматизировать даже сложные процессы, с другой совершенно идиотский и неконсистентный синтаксис с динамической типизацией.
Например, работа с коллекцией через foreach(obj in $list) {...} и через $list | Foreach-Object {...} разнится и зачастую непредсказуемо, если внутри блока использовать continue, break или return или код внутри блока выкидывает исключение.
За двойные стандарты вызова функций авторов PowerShell нужно отправить в несгораемый котел: почему одним функциям нужно передавать параметр через Set-Value -Parameter "Hi", а другим через "string".Split(";")? Эта неконсистентость только усиливается классами, пример которых представлен в статье. Если я объявляю функцию модуля, то она будет вызваться как Get-Something, но если я создаю класс, то это уже ClassInstance.Get($something). Я кучу часов потратил на отладку неработающего кода, из-за того, что скопировал функцию из объявления Invoke-Something($a = "aaa", $b = "bbb) и забыл убрать скобки!
Еще одна болезнь — толерантность к пустым переменным. Я плачу по strict режиму, чтобы нельзя было использовать необъявленные и неинициализированные переменные. Куча времени уходит на поимку фантомов, после того, как в одном месте изменяется название переменной, а ниже по пайпу она продолжает использоваться как ни в чем не бывало. Еще хуже с этим дела обстоят в PowerShell ISE, который будет хранить временное значение переменной до перезапуска, а вы будете себе рвать волосы на голове, не понимая почему значение переменной $MuVar не меняется, хотя выше по коду $MyVar давно имеет новое значение.
можно внедрить в проекте Directory.Build.props and Directory.Build.targets. в конце концов достаточно таргет фреймворк поменять и в большинстве случаев всё будет работать без каких-либо видимых изменений на новой версии фреймворка, а для обновления зависимостей в студии достаточно на уровне солюшена нажать кнопку Manage Packages.
ИМХО плюсы раскрываются только в гомогенной среде, где System.Text.Json используется и сервером и клиентом. В реальной жизни у микрософтовской реализации куча ограничений, многие конвертеры нужно писать с нуля, хуже устойчивость к ошибкам. Для нашего проекта небольшой потенциальный выигрыш в меньшем расходе памяти не смог перевесить необходимость написания и поддержания целой библиотеки сопутствующих конвертеров. А если поискать ещё немного, можно убедиться, что помимо System.Text.Json и Newtonsoft.Json есть библиотеки и с большей пропускной способностью и с меньшим потреблением ресурсов.
Пока что официальная позиция — поддерживайте старый код как есть, мы его не будем ломать. Начинайте новые проекты с .NET Core. Вроде попадаются комментарии об автоматических/полуавтоматических конвертерах FX=>Core. Для Core 3.1 вроде как есть интероп для «классических» библиотек, но часть стека так и останется навсегда в старом FX.
ничего они не объединятся. .NET FX (3.5-4.8) останется жит в стадии замороженной функциональности, будет поддерживаться вплоть до окончания жизни платформ, на которых он изначально вышел (а это Windows Server 2012-2019 и параллельные им Windows Desktop версии), а все новые фичи будут выходить ежегодно под флагом очередного .NET, который является ребрендингом .NET Core.
Правильно. Хипы наше всё. Нужны случайно монотонные PK. Интересно, автор знает почему эти рекомендации существуют?
First-class поддежрка Value Objects планируется в EF Core 8.0: Plan for Entity Framework Core 8. Можно поддержать идею на GitHub
Есть репозиторий с примерами: Telegram.Bot.Examples
Посмотри раздел Downloading files нашей документации.
Тоже не с первого раза заметил. По всей видимости речь идет о клиенте:
Почти год назад Windows Terminal уже упрекали в медлительности. Casey Muratori даже набросал прототип терминала, который выдавал тысячи FPS на рендеринге.
В результате Windows Terminal адаптировал новый rendering engine. Интересно, насколько это изменение связано с проблемой, разобранной в статье?
На фоне графиков потребления и заявлений о более высокой энергоэффективности интересно выглядит новый блок на 140 Вт против старого на 96.
во всех вменяемых стайлгайдах многострочный if всегда обрамляется скобками. а если следовать правилу fail-fast то после if должен стоять return.
Со всеми этими Mr, Ms, Sir и им подобными обращениями очень легко в современной "толерантной" среде нажить себе проблем. Мало ли как себя оппонент идентифицирует (He, She, They) и обращение с "половым" уклоном легко может спровоцировать если не конфликт, то серьезное недопонимание.
Вот например "женщину" оскорбили на конференции:
Справедливости ради, на презентации сказали, что докер на новой платформе будет запускать образ с ARM-версией ядра. А это значит, что образ-то может и запустится, но поведение его может отличаться от продуктовой среды, потому что серверная инфраструктура на 99% это x86.
в .NET 5.0 аннотировали почти 90% BCL и будут добавлять аннотации по мере развития языка
Окей гугл: как пройтись по всем сайтовым коллекциям SharePoint и почистить в них корзину из LINQPad? Как в несколько шагов организовать миграцию для SQL Server по аналогии с dbatools?
Может для программиста и проще накидать скетч на C#, а для администратора проще написать скрипт на повершеле. Тем более, что управление инфраструктурой Microsoft построено вокруг PowerShell.
А зачем строки менять? PowerShell десериализует JSON в объект и достаточно будет поменять свойство нужных полей, а потом сериализовать и отправить ответ:
Причем неважно откуда будет получен исходный объект — прочитан из файла, из запроса или сформирован через переменные PowerShell.
Люблю и ненавижу PowerShell. С одной стороны позволяет с легкостью автоматизировать даже сложные процессы, с другой совершенно идиотский и неконсистентный синтаксис с динамической типизацией.
Например, работа с коллекцией через
foreach(obj in $list) {...}и через$list | Foreach-Object {...}разнится и зачастую непредсказуемо, если внутри блока использовать continue, break или return или код внутри блока выкидывает исключение.За двойные стандарты вызова функций авторов PowerShell нужно отправить в несгораемый котел: почему одним функциям нужно передавать параметр через
Set-Value -Parameter "Hi", а другим через"string".Split(";")? Эта неконсистентость только усиливается классами, пример которых представлен в статье. Если я объявляю функцию модуля, то она будет вызваться какGet-Something, но если я создаю класс, то это ужеClassInstance.Get($something). Я кучу часов потратил на отладку неработающего кода, из-за того, что скопировал функцию из объявленияInvoke-Something($a = "aaa", $b = "bbb)и забыл убрать скобки!Еще одна болезнь — толерантность к пустым переменным. Я плачу по strict режиму, чтобы нельзя было использовать необъявленные и неинициализированные переменные. Куча времени уходит на поимку фантомов, после того, как в одном месте изменяется название переменной, а ниже по пайпу она продолжает использоваться как ни в чем не бывало. Еще хуже с этим дела обстоят в PowerShell ISE, который будет хранить временное значение переменной до перезапуска, а вы будете себе рвать волосы на голове, не понимая почему значение переменной $MuVar не меняется, хотя выше по коду $MyVar давно имеет новое значение.
А вот и то, о чем я говорил. Performance review закончился, Келлер ушёл: https://newsroom.intel.com/news-releases/changes-intels-technology-systems-architecture-client-group/