Дичь с in-memory БД
Два месяца назад я основательно переделал свой пет-проект. Модульные тесты частично сломались, но сил у меня на них тогда не было. И вот дошли таки руки, занялся рефакторингом. И всплыл... ну, не баг, видимо, а странное поведение, скажем так.
Есть совершенно классического вида репозиторий, который инкапсулирует
И вот один тест падает. Тестируется там метод, возвращающий отсортированную коллекцию строк, причем строки сортирует БД. В продакшене метод работает как ожидается, в тестовом окружении — нет.
Оказалось, что раньше в строках, которые сортируются, были только строки, начинающиеся с символов кириллицы, а сейчас появились и строки, начинающиеся с символов латиницы, что, собственно, и было сутью большой переделки проекта. И вот Microsoft SQL Server сортирует их ожидаемо: сначала идут строки с символами латиницы в начале, а затем идут строки с символами кириллицы в начале. А вот in-memory БД сортирует наоборот. При этом внутри этих двух групп всё сортируется правильно в обоих случаях.
Как починить пока не придумал. Потому что как сконфигурировать сортировку строк в in-memory БД и возможно ли это вообще — не понятно, а попытка в лоб передать какой-нибудь comparer в
#dotnet #csharp #unittesting #databases
Два месяца назад я основательно переделал свой пет-проект. Модульные тесты частично сломались, но сил у меня на них тогда не было. И вот дошли таки руки, занялся рефакторингом. И всплыл... ну, не баг, видимо, а странное поведение, скажем так.
Есть совершенно классического вида репозиторий, который инкапсулирует
DbContext из EF Core и использует обычный LINQ to Entities для формирования запросов. В продакшене контекст кофигурируется для работы с Microsoft SQL Server. В тестовом окружении для модульных тестов я вместо него использую in-memory БД:public static ApplicationDbContext CreateApplicationDbContextInMemory()
{
var contextOptions = new DbContextOptionsBuilder<ApplicationDbContext>()
.UseInMemoryDatabase(databaseName: Guid.NewGuid().ToString())
.Options;
return new ApplicationDbContext(contextOptions);
}
И вот один тест падает. Тестируется там метод, возвращающий отсортированную коллекцию строк, причем строки сортирует БД. В продакшене метод работает как ожидается, в тестовом окружении — нет.
Оказалось, что раньше в строках, которые сортируются, были только строки, начинающиеся с символов кириллицы, а сейчас появились и строки, начинающиеся с символов латиницы, что, собственно, и было сутью большой переделки проекта. И вот Microsoft SQL Server сортирует их ожидаемо: сначала идут строки с символами латиницы в начале, а затем идут строки с символами кириллицы в начале. А вот in-memory БД сортирует наоборот. При этом внутри этих двух групп всё сортируется правильно в обоих случаях.
Как починить пока не придумал. Потому что как сконфигурировать сортировку строк в in-memory БД и возможно ли это вообще — не понятно, а попытка в лоб передать какой-нибудь comparer в
OrderBy приводит к «The LINQ expression could not be translated» и ссылке на статью «Client vs. Server Evaluation». Понятно, что серверной стороне виднее, только тут серверная сторона — in-memory БД, и у нее свои очень своеобразные представления о прекрасном. 🤔#dotnet #csharp #unittesting #databases
👍6🤔3❤1🔥1
Осьминогов вам в ленту
Сегодня напоролся на прекрасное, не могу не поделиться.
Делаю задачу в своей ветке, там 8 коммитов. По просьбе коллеги сделал пулл-реквест сильно заранее, еще после первого коммита. Вообще, я за то, чтобы после полной готовности все коммиты сквошить в один и только тогда делать пул-реквест, но задача прямо объемная, там что-то около 100 измененных файлов, и коллеге удобнее ревьюить частями, он это делает по ходу появления коммитов в пулл-реквесте.
И вот в середине этого списка у меня коммит с описанием вида «Added feature to A & B applications». На автомате написал, не ждал подвоха. Всё окей, коллега аппрувит пулл-реквест, мерджим его в
Последний день спринта, 20 минут до конца рабочего дня, и тикет хорошо бы закрыть. А оно, блин, не деплоится из-за какого-то XML-файла.
Спросили совета у девопса, гуру Octopus'а. Оказалось прекрасное. Octopus генерирует
Решение гуру посоветовал прекрасное и — главное — рабочее: ничего менять не надо, не надо ребейсить и убирать из сообщения коммита амперсанд, а надо просто еще раз запустить билд из
Чуть не поседел, в общем. Спасибо гуру.
#octopus #cicd
Сегодня напоролся на прекрасное, не могу не поделиться.
Делаю задачу в своей ветке, там 8 коммитов. По просьбе коллеги сделал пулл-реквест сильно заранее, еще после первого коммита. Вообще, я за то, чтобы после полной готовности все коммиты сквошить в один и только тогда делать пул-реквест, но задача прямо объемная, там что-то около 100 измененных файлов, и коллеге удобнее ревьюить частями, он это делает по ходу появления коммитов в пулл-реквесте.
И вот в середине этого списка у меня коммит с описанием вида «Added feature to A & B applications». На автомате написал, не ждал подвоха. Всё окей, коллега аппрувит пулл-реквест, мерджим его в
main. Octopus пытается опубликовать пакет и падает с ошибкой парсинга XML-файла. Думаем, WTF?!? Какой еще XML-файл он там не может распарсить?!?Последний день спринта, 20 минут до конца рабочего дня, и тикет хорошо бы закрыть. А оно, блин, не деплоится из-за какого-то XML-файла.
Спросили совета у девопса, гуру Octopus'а. Оказалось прекрасное. Octopus генерирует
nuspec-файл, в который добавляет список сообщений всех новых коммитов, появившихся после последнего билда из main'а. Включая то самое сообщение «Added feature to A & B applications». После чего пытается его распарсить и падает на не экранированном амперсанде.Решение гуру посоветовал прекрасное и — главное — рабочее: ничего менять не надо, не надо ребейсить и убирать из сообщения коммита амперсанд, а надо просто еще раз запустить билд из
main'а. Octopus заново сгенерирует nuspec-файл, и поскольку там должны быть только новые коммиты по сравнению с предыдущим билдом, а никаких новых коммитов нет, то сообщений там вообще не будет, никаких тебе неэкранированных амперсандов, и всё соберется.Чуть не поседел, в общем. Спасибо гуру.
#octopus #cicd
🔥13😁7👍3🤯2👨💻2🤡1🏆1
Online .NET Hackathon 2024
Мы тут в @hys_enterprise опять организуем хакатон: https://t.me/hys_events/204.
Я опять буду одним из менторов. В позапрошлом году одна из команд, которых я менторил, даже выиграла. Не то, чтобы я имел к их успеху хоть сколько-нибудь значимое отношение, ребята сами прекрасно справились, но было весело всем. 😉
Приходите, кому интересно. Уверен, снова будет весело. 🙂
#hys_enterprise #hackathon #dotnet #csharp
Мы тут в @hys_enterprise опять организуем хакатон: https://t.me/hys_events/204.
Я опять буду одним из менторов. В позапрошлом году одна из команд, которых я менторил, даже выиграла. Не то, чтобы я имел к их успеху хоть сколько-нибудь значимое отношение, ребята сами прекрасно справились, но было весело всем. 😉
Приходите, кому интересно. Уверен, снова будет весело. 🙂
#hys_enterprise #hackathon #dotnet #csharp
Telegram
HYS Events
Якщо ви вмієте писати код на C#. Прагнете займатися розробкою та розв’язувати дилеми не штучного проєкту — тоді приєднуйтеся на ONLINE .NET HACKATHON 2024!
Що потрібно знати для участі?
▪️ Навички роботи з ASP.NET Core;
▪️ Вміння працювати з Telegram…
Що потрібно знати для участі?
▪️ Навички роботи з ASP.NET Core;
▪️ Вміння працювати з Telegram…
❤🔥5❤5
На пути к фулстеку 😉
Сегодня я закончил свой первый тикет, включавший не только бэкенд, но и фронтенд. У нас есть внутренний портал и он сделан на TypeScript + React. Ну и вот. 😎
Давно я уже не лазил в справочники за половиной нужных синтаксических конструкций. Причем в справочники и по JavaScript, и по TypeScript. И отдельно в документацию по React. Но было интересно.
Буду и дальше JavaScript/TypeScript и React копать. Благо прямо на работе такие тикеты еще будут. И, если немного времени после работы появится, за какой-нибудь пет-проект возьмусь, чтобы прямо вот с нуля всё самому и на фронтенде сделать.
Кто бы мог подумать... 😁
#программистыэтонеигра #frontend #react #typescript #fullstack
Сегодня я закончил свой первый тикет, включавший не только бэкенд, но и фронтенд. У нас есть внутренний портал и он сделан на TypeScript + React. Ну и вот. 😎
Давно я уже не лазил в справочники за половиной нужных синтаксических конструкций. Причем в справочники и по JavaScript, и по TypeScript. И отдельно в документацию по React. Но было интересно.
Буду и дальше JavaScript/TypeScript и React копать. Благо прямо на работе такие тикеты еще будут. И, если немного времени после работы появится, за какой-нибудь пет-проект возьмусь, чтобы прямо вот с нуля всё самому и на фронтенде сделать.
Кто бы мог подумать... 😁
#программистыэтонеигра #frontend #react #typescript #fullstack
👍9😁4😨3❤🔥2👀2❤1🔥1
Microsoft, ну, ё-моё 😡
Вчера был второй вторник месяца, а значит Microsoft выкатила кумулятивный апдейт для Windows за месяц и заодно, как это часто бывает, апдейт для Visual Studio. Я как раз один раз в месяц все такие обновления скопом накатываю. Хоть перегружаться надо только один раз, а то я это дело очень не люблю.
На личном лэптопе всё обновилось, перегрузился, Visual Studio запустилась, всё окей. А на рабочем Visual Studio обновилась, но после этого стала глухо зависать при старте. А мне работать надо...
В общем, пришлось ей делать Repair. А Repair — это, во-первых, долго, а во-вторых, сброс всех настроек. Хорошо хоть настройки Visual Studio у меня сохраняются автоматически в специальную папку, я их накатил и, кроме расширений, всё вернулось как было.
Но Microsoft, ну, ё-моё же ж... 🤦🏻♂️
#microsoft #visualstudio #трудовыебудни
Вчера был второй вторник месяца, а значит Microsoft выкатила кумулятивный апдейт для Windows за месяц и заодно, как это часто бывает, апдейт для Visual Studio. Я как раз один раз в месяц все такие обновления скопом накатываю. Хоть перегружаться надо только один раз, а то я это дело очень не люблю.
На личном лэптопе всё обновилось, перегрузился, Visual Studio запустилась, всё окей. А на рабочем Visual Studio обновилась, но после этого стала глухо зависать при старте. А мне работать надо...
В общем, пришлось ей делать Repair. А Repair — это, во-первых, долго, а во-вторых, сброс всех настроек. Хорошо хоть настройки Visual Studio у меня сохраняются автоматически в специальную папку, я их накатил и, кроме расширений, всё вернулось как было.
Но Microsoft, ну, ё-моё же ж... 🤦🏻♂️
#microsoft #visualstudio #трудовыебудни
🙈5😱3
С Новым годом!
С Новым годом, други! Спасибо вам, что были со мной весь этот год. Без вас этого канала точно бы не было. ❤️
С пожеланиями сложно быть оригинальным. Просто хочу пожелать вам всем мира, здоровья и счастья, где бы вы ни находились в данный момент. И, конечно, пусть в вашей работе кайф от качественно и в срок решенных вами инженерных задач превышает все отрицательные эмоции, которые могут возникать в процессе. 😉
Люблю вас всех. Stay tuned. 😎
#программистыэтонеигра #devsarenotagame #softwareenineering
С Новым годом, други! Спасибо вам, что были со мной весь этот год. Без вас этого канала точно бы не было. ❤️
С пожеланиями сложно быть оригинальным. Просто хочу пожелать вам всем мира, здоровья и счастья, где бы вы ни находились в данный момент. И, конечно, пусть в вашей работе кайф от качественно и в срок решенных вами инженерных задач превышает все отрицательные эмоции, которые могут возникать в процессе. 😉
Люблю вас всех. Stay tuned. 😎
#программистыэтонеигра #devsarenotagame #softwareenineering
❤🔥29🎉6❤5🔥5👍2
Блеск и нищета Open Source, часть 2
Тут очередной скандал в благородном семействе. В смысле, в .NET-сообществе.
Есть такая библиотека — FluentAssertions. В целом, из названия понятно, что она просто позволяет записывать Assert'ы в тестах во fluent-стиле. Это действительно само по себе красиво и удобно, но — главное — делает Assert'ы гораздо понятнее, потому что классические Assert'ы из NUnit и xUnit сделаны чужими для хищников, на мой взгляд. При этом разработчики NUnit давно это понимают и, опять же, давно сделали помимо Classic Model еще и Constraint Model — типа-fluent-стиль для Assert'ов в виде
Но! Это просто вспомогательная библиотека для записи Assert'ов, не более. Никакой бизнес-задачи, кроме некоторой экономии времени на написание тестов и чтение их потом, она не решает. Кроме того, у нее существует конкурент — библиотека Shoudly, которая делает всё то же, но просто чуть менее элегантно.
Обе библиотеки бесплатные. До вчерашнего дня. Со вчера бесплатной осталась только Shoudly, а FluentAssertions, начиная с версии 8.0, теперь платная для коммерческих продуктов при условии, что компания имеет от 1 миллиона $ дохода в год.
А теперь самое забавное — это цена. А именно: 130$ в год на одного разработчика. Для сравнения: целый JetBrains Rider стоит 150$ за первый год, а дальше дешевле. А тут библиотека для записи Assert'ов — 130$.
Собственно, народ недоумевает: https://github.com/fluentassertions/fluentassertions/pull/2943. Там много разного, в том числе полно просто любителей халявы, считающих, что им все должны, но две здравые мысли там видны четко: во-первых, все не понимают этого дикого ценообразования, а во-вторых, задаются вопросом о том, корректно ли от Apache-лицензии вот так вот просто переходить к коммерческой лицензии. По второму пункту ничего сказать не могу, хотя думаю, что авторы библиотеки не полные идиоты и домашнюю работу сделали, прежде, чем ударяться во все тяжкие.
Нигде я пока не видел ни одного коммента от разработчиков, где говорят, что их устраивает, будут платить. И из-за цены, и вообще. Вариантов реакции у сообщества два: «заменим FluentAssertions на Shoudly» и «пока просто останемся на 7.0, а там посмотрим». Потому что даже если у кого-то и есть желание ничего в коде не менять и заплатить, никто из разработчиков не знает как объяснить бизнесу необходимость потратить такую сумму на решение такой задачи.
Мы тоже используем FluentAssertions. И тоже первое, что сделали, это приняли меры, чтобы случайно не обновиться до 8.0.
Этот выход из шкафа авторам FluentAssertions удался, конечно, лучше, чем автору Moq, но всё равно как разумно монетизировать свой вклад в библиотеки с открытым исходным кодом в .NET-сообществе пока, видимо, никто не придумал.
#csharp #dotnet #unittesting #tooling
Тут очередной скандал в благородном семействе. В смысле, в .NET-сообществе.
Есть такая библиотека — FluentAssertions. В целом, из названия понятно, что она просто позволяет записывать Assert'ы в тестах во fluent-стиле. Это действительно само по себе красиво и удобно, но — главное — делает Assert'ы гораздо понятнее, потому что классические Assert'ы из NUnit и xUnit сделаны чужими для хищников, на мой взгляд. При этом разработчики NUnit давно это понимают и, опять же, давно сделали помимо Classic Model еще и Constraint Model — типа-fluent-стиль для Assert'ов в виде
Assert.That. «Типа» — потому что, это, конечно, лучше, чем классика, но до нормального все-таки не доходит. Так вот, FluentAssertions делает это прямо красиво. Я в своих личных проектах давно ее использую — лет эдак 8, что ли.Но! Это просто вспомогательная библиотека для записи Assert'ов, не более. Никакой бизнес-задачи, кроме некоторой экономии времени на написание тестов и чтение их потом, она не решает. Кроме того, у нее существует конкурент — библиотека Shoudly, которая делает всё то же, но просто чуть менее элегантно.
Обе библиотеки бесплатные. До вчерашнего дня. Со вчера бесплатной осталась только Shoudly, а FluentAssertions, начиная с версии 8.0, теперь платная для коммерческих продуктов при условии, что компания имеет от 1 миллиона $ дохода в год.
А теперь самое забавное — это цена. А именно: 130$ в год на одного разработчика. Для сравнения: целый JetBrains Rider стоит 150$ за первый год, а дальше дешевле. А тут библиотека для записи Assert'ов — 130$.
Собственно, народ недоумевает: https://github.com/fluentassertions/fluentassertions/pull/2943. Там много разного, в том числе полно просто любителей халявы, считающих, что им все должны, но две здравые мысли там видны четко: во-первых, все не понимают этого дикого ценообразования, а во-вторых, задаются вопросом о том, корректно ли от Apache-лицензии вот так вот просто переходить к коммерческой лицензии. По второму пункту ничего сказать не могу, хотя думаю, что авторы библиотеки не полные идиоты и домашнюю работу сделали, прежде, чем ударяться во все тяжкие.
Нигде я пока не видел ни одного коммента от разработчиков, где говорят, что их устраивает, будут платить. И из-за цены, и вообще. Вариантов реакции у сообщества два: «заменим FluentAssertions на Shoudly» и «пока просто останемся на 7.0, а там посмотрим». Потому что даже если у кого-то и есть желание ничего в коде не менять и заплатить, никто из разработчиков не знает как объяснить бизнесу необходимость потратить такую сумму на решение такой задачи.
Мы тоже используем FluentAssertions. И тоже первое, что сделали, это приняли меры, чтобы случайно не обновиться до 8.0.
Этот выход из шкафа авторам FluentAssertions удался, конечно, лучше, чем автору Moq, но всё равно как разумно монетизировать свой вклад в библиотеки с открытым исходным кодом в .NET-сообществе пока, видимо, никто не придумал.
#csharp #dotnet #unittesting #tooling
🤣5👍2🔥2
Управление версиями пакетов
Вдогонку к предыдущему посту узнал вчера прекрасное: в
Сначала просто как зафиксировать версию пакета так, чтобы тулинг не предлагал вам ее обновить, даже если в NuGet-репозитории появляется новая версия. Вместо обычного:
пишем
Но оказалось, что всё еще круче и фишка здесь не просто в том, что вот есть такой синтаксис с квадратными скобками, а в том, что этот синтаксис — это частный случай полноценных диапазонов:
Т.е. классическая математическая запись с «включая значение» (квадратная скобка) и «не включая значение» (круглая скобка). Всё, теперь можно спокойно обновляться до любой версии — тулинг будет предлагать только версии, больше либо равные 7.0.0, но меньшие 8.0.0.
Есть, конечно, еще вариант с маской (
Автор обещал, что 7-ю пока не забрасывает и будет обновлять (баги, патчи, вот это всё). Ну, поглядим.
#csharp #dotnet #unittesting #tooling
Вдогонку к предыдущему посту узнал вчера прекрасное: в
csjproj-файлах оказывается можно красиво ограничить возможные версии для пакета.Сначала просто как зафиксировать версию пакета так, чтобы тулинг не предлагал вам ее обновить, даже если в NuGet-репозитории появляется новая версия. Вместо обычного:
<PackageReference Include="FluentAssertions" Version="7.0.0" />
пишем
<PackageReference Include="FluentAssertions" Version="[7.0.0]" />
Но оказалось, что всё еще круче и фишка здесь не просто в том, что вот есть такой синтаксис с квадратными скобками, а в том, что этот синтаксис — это частный случай полноценных диапазонов:
<PackageReference Include="FluentAssertions" Version="[7.0.0,8.0.0)" />
Т.е. классическая математическая запись с «включая значение» (квадратная скобка) и «не включая значение» (круглая скобка). Всё, теперь можно спокойно обновляться до любой версии — тулинг будет предлагать только версии, больше либо равные 7.0.0, но меньшие 8.0.0.
Есть, конечно, еще вариант с маской (
7.*), если так кому-то больше нравится.Автор обещал, что 7-ю пока не забрасывает и будет обновлять (баги, патчи, вот это всё). Ну, поглядим.
#csharp #dotnet #unittesting #tooling
🔥12❤🔥1🥰1🤯1
Загадочный тулинг TypeScript
Разбираюсь тут понемногу с TypeScript. Пишу что-то и сразу смотрю в какой JavaScript-код оно транспилируется. Я не копенгаген в JavaScript'е, но лучше всё равно представлять, что происходит.
Так вот, пишу кое-что и внутри использую обычную интерполяцию, которая вообще-то не является особенностью TypeScript, а вроде как родная для самого JavaScript'а. Ну, т.е. ничего менять не надо, оставляй как есть. А на деле вот это:
tsc внезапно превращает вот в это:
Что?!? Зачем? Почему? Второй вариант в JavaScript производительнее, чем его же интерполяция?
Ну, вот зачем они так на ровном месте, а? 🙁
P.S. Там в группе для комментов, присоединенной к каналу, объяснили, что это ради обратной совместимости: старый JavaScript не поддерживал интерполяцию.
#javascipt #typescript #fontend #tooling
Разбираюсь тут понемногу с TypeScript. Пишу что-то и сразу смотрю в какой JavaScript-код оно транспилируется. Я не копенгаген в JavaScript'е, но лучше всё равно представлять, что происходит.
Так вот, пишу кое-что и внутри использую обычную интерполяцию, которая вообще-то не является особенностью TypeScript, а вроде как родная для самого JavaScript'а. Ну, т.е. ничего менять не надо, оставляй как есть. А на деле вот это:
let result = `${greeting}, ${name}!`;tsc внезапно превращает вот в это:
var result = "".concat(greeting, ", ").concat(name, "!");
Что?!? Зачем? Почему? Второй вариант в JavaScript производительнее, чем его же интерполяция?
Ну, вот зачем они так на ровном месте, а? 🙁
P.S. Там в группе для комментов, присоединенной к каналу, объяснили, что это ради обратной совместимости: старый JavaScript не поддерживал интерполяцию.
#javascipt #typescript #fontend #tooling
❤6👍1
AutoMapper, MediatR, and MassTransit Going Commercial
Очередная драма в .NET-сообществе (ну, вы же знали, что я не смогу об этом не написать, да? 😉). Три о-о-о-очень популярные библиотеки переходят на платное лицензирование (ссылка номер раз: AutoMapper and MediatR Going Commercial, ссылка номер два: Announcing MassTransit v9). Отличие этих историй от истории с FluentAssertions в том, что авторы, видимо, выучили урок и будут это делать как-то умнее. Но пока, правда, не говорят как именно. Сначала обозначили намеренья, конкретику с ценами дадут позже.
Желание авторов начать зарабатывать на том, во что вложены годы в основном их труда (а не комьюнити), целиком и полностью понятно. Не понятно, что теперь делать .NET-разработчикам. Мы до сих пор еще FluentAssertions выковыриваем, а тут и вот с этим тоже нужно будет теперь что-то решать. И как после этого доверять этой хваленной OSS-экосистеме?
Как решать проблему в целом — я не знаю. И не знаю как эта проблема решается в других экосистемах. Есть же громадная экосистема Java и всего, что поверх нее выстроено. В мире JavaScript/TypeScript есть не только библиотеки, но даже целые огромные фреймворки. Есть куча всего для Python, есть для новомодного Go. Везде есть OSS-проекты, некоторые из которых живут десятилетиями. Как-то же там эта проблема решена?
Возможно, решать такую проблему в своей экосистеме имеет смысл Microsoft'у. А то фреймворки фреймворками, но мы все знаем, что за вроде как OOS-проектом Angular стоит Google, а за за вроде как OOS-проектом React стоит Facebook. И, будем честны, если они бросят это дело, то загнуться оба фреймворка как миленькие. Вот, может, и Microsoft'у имеет смысл как-то поддерживать популярные OOS-проекты в их экосистеме. Если они, конечно, в этом заинтересованы.
В общем, вчерашняя ситуация высветила проблему уже не просто фонариком, а прямо уже прожектором. Посмотрим, будут ли какие-либо изменения.
#dotnet #microsoft #tooling
Очередная драма в .NET-сообществе (ну, вы же знали, что я не смогу об этом не написать, да? 😉). Три о-о-о-очень популярные библиотеки переходят на платное лицензирование (ссылка номер раз: AutoMapper and MediatR Going Commercial, ссылка номер два: Announcing MassTransit v9). Отличие этих историй от истории с FluentAssertions в том, что авторы, видимо, выучили урок и будут это делать как-то умнее. Но пока, правда, не говорят как именно. Сначала обозначили намеренья, конкретику с ценами дадут позже.
Желание авторов начать зарабатывать на том, во что вложены годы в основном их труда (а не комьюнити), целиком и полностью понятно. Не понятно, что теперь делать .NET-разработчикам. Мы до сих пор еще FluentAssertions выковыриваем, а тут и вот с этим тоже нужно будет теперь что-то решать. И как после этого доверять этой хваленной OSS-экосистеме?
Как решать проблему в целом — я не знаю. И не знаю как эта проблема решается в других экосистемах. Есть же громадная экосистема Java и всего, что поверх нее выстроено. В мире JavaScript/TypeScript есть не только библиотеки, но даже целые огромные фреймворки. Есть куча всего для Python, есть для новомодного Go. Везде есть OSS-проекты, некоторые из которых живут десятилетиями. Как-то же там эта проблема решена?
Возможно, решать такую проблему в своей экосистеме имеет смысл Microsoft'у. А то фреймворки фреймворками, но мы все знаем, что за вроде как OOS-проектом Angular стоит Google, а за за вроде как OOS-проектом React стоит Facebook. И, будем честны, если они бросят это дело, то загнуться оба фреймворка как миленькие. Вот, может, и Microsoft'у имеет смысл как-то поддерживать популярные OOS-проекты в их экосистеме. Если они, конечно, в этом заинтересованы.
В общем, вчерашняя ситуация высветила проблему уже не просто фонариком, а прямо уже прожектором. Посмотрим, будут ли какие-либо изменения.
#dotnet #microsoft #tooling
❤9❤🔥4
Тут годноту подвезли
Сережа Гречко, один из моих тимлидов, у которого я очень многому научился (в первую очередь — взгляду на профессию как на инженерную дисциплину), завел свой YouTube-канал. Там много Linux'а и его тулинга, но главное — много сути происходящего, что, на мой взгляд, будет полезно и тем, кто работает с Windows. Так что очень рекомендую.
#youtube #softwareengineering
Сережа Гречко, один из моих тимлидов, у которого я очень многому научился (в первую очередь — взгляду на профессию как на инженерную дисциплину), завел свой YouTube-канал. Там много Linux'а и его тулинга, но главное — много сути происходящего, что, на мой взгляд, будет полезно и тем, кто работает с Windows. Так что очень рекомендую.
#youtube #softwareengineering
❤11👍6👏1
Маленькие радости .NET-разработчика
Вы не поверите, но в EF Core 10 (ну, технически — в LINQ to Entities) завезут нормальные
Не сказать, конечно, что реализовать
1. Связка
Как-то так это выглядит сейчас:
2. Метод расширения
И вот теперь прямо можно будет по-человечески писать (ровно как в LinqKit):
Плюс аналогичный
Неизвестно пока одно: это только в EF Core 10 / LINQ to Entities завезут или в LINQ to Objects для всех тоже?
#dotnet #dotnet10 #efcore #linq
Вы не поверите, но в EF Core 10 (ну, технически — в LINQ to Entities) завезут нормальные
LeftJoin и RightJoin. Наконец-то. 🤦🏻♂️Не сказать, конечно, что реализовать
LEFT / RIGHT JOIN в LINQ раньше было нельзя. Можно, конечно, а то не понятно тогда было бы как вообще работать. Какие были варианты?1. Связка
GroupJoin + SelectMany + DefaultIfEmpty, чтобы реализовать LEFT JOIN. Ну, два метода вместо одного — это еще ладно. А вот неочевидность и плохая читабельность этого подхода — на лицо. Кстати, RIGHT JOIN можно было реализовать только через LEFT JOIN записью наоборот, что еще больше добавляло неочевидности и еще больше ухудшало читабельность. Ну, хоть работало не только для LINQ to Entities, но вообще для LINQ to Objects, т.е. в таком виде саму операцию можно было применять к любым IEnumerable-коллекциям, не только к EF Core'ному IQueryable.Как-то так это выглядит сейчас:
var booksByOldFashionedWay = context.Books
.GroupJoin(
context.Authors,
book => book.AuthorFk,
author => author.Id,
(book, authors) => new { book, authors })
.SelectMany(
left => left.authors.DefaultIfEmpty(),
(booksAndAuthors, author) => new
{
booksAndAuthors.book,
author
})
.Select(x => new
{
AuthorName = x.author.Name,
x.booksAndAuthors.book.Name
});
2. Метод расширения
LeftJoin из прекрасной библиотеки LinqKit. Только для LEFT JOIN, кстати, RIGHT JOIN и там нет, но поскольку библиотека вообще не про это, главная ее фишка в другом, так что и за LEFT JOIN большое спасибо, вот правда.И вот теперь прямо можно будет по-человечески писать (ровно как в LinqKit):
var booksByShinyNewWay = context.Books
.LeftJoin(
context.Authors,
book => book.AuthorFk,
author => author.Id,
(book, author) => new { book, author })
.Select(x => new
{
AuthorName = x.author.Name,
x.book.Name
});
Плюс аналогичный
RightJoin, которого в LinqKit нет.Неизвестно пока одно: это только в EF Core 10 / LINQ to Entities завезут или в LINQ to Objects для всех тоже?
#dotnet #dotnet10 #efcore #linq
👍5🔥3😍2
Хорошая новость с Build'а
Ну, наконец-то. Начиная с .NET 10 на C# можно будет писать скрипты: https://www.youtube.com/watch?v=98MizuB7i-w. Ну, т.е что угодно, не обязательно только скрипты в классическом понимании, можно хоть API-сервис так поднять (в видео, кстати, это тоже есть), но понятно, что если нужна простенькая программка в одном
Ни файла проекта, ничего не нужно, только
А под Линуксом так вообще
Запускается, соответственно, как и любой скрипт, если, конечно, ему предварительно атрибут соответствующий задать:
И, конечно,
Кому как, а я давно такое хотел. Под Windows хотел, не под Linux, просто скрипты на C# для личного пользования, вот это всё. 👍
P.S. Продают они это, конечно, как очередное понижение порога вхождения в C# для начинающих. Мол, у всех так можно, у Python, у JavaScript/Node.js, у Go, даже у Rust, говорят, можно, а теперь, мол, и у нас. Ну, не знаю, наверное, кому-то это поможет на начальном этапе, хотя лично я бы всё равно так людей не учил — это, на мой взгляд, порочный путь. Но если задача — просто побороться с Python за неокрепшие умы, пишущие что-то простое и не собирающиеся в программисты, то, возможно, и сработает, да.
P.P.S. И заметьте, это, видимо, первый доклад на Build, где ни разу не вставили упоминание AI. 😁 Даже удивительно как-то. Хотя вполне можно предположить, что они именно из-за AI у Python'а кусок рынка и собрались откусить. 😉
#csharp #dotnet10
Ну, наконец-то. Начиная с .NET 10 на C# можно будет писать скрипты: https://www.youtube.com/watch?v=98MizuB7i-w. Ну, т.е что угодно, не обязательно только скрипты в классическом понимании, можно хоть API-сервис так поднять (в видео, кстати, это тоже есть), но понятно, что если нужна простенькая программка в одном
cs-файле, то на какую-то мегафунциональность мы по-любому не замахиваемся.Ни файла проекта, ничего не нужно, только
cs-файл:dotnet run script.cs
А под Линуксом так вообще
#!: поддерживается, прямо как в лучших домах Ландона:#!/usr/bin/dotnet run
Console.WriteLine("Hi!");
Запускается, соответственно, как и любой скрипт, если, конечно, ему предварительно атрибут соответствующий задать:
$ chmod +х script.cs
$ ./script.cs
И, конечно,
argv работает, так что можно и параметры передавать. В общем, песня.Кому как, а я давно такое хотел. Под Windows хотел, не под Linux, просто скрипты на C# для личного пользования, вот это всё. 👍
P.S. Продают они это, конечно, как очередное понижение порога вхождения в C# для начинающих. Мол, у всех так можно, у Python, у JavaScript/Node.js, у Go, даже у Rust, говорят, можно, а теперь, мол, и у нас. Ну, не знаю, наверное, кому-то это поможет на начальном этапе, хотя лично я бы всё равно так людей не учил — это, на мой взгляд, порочный путь. Но если задача — просто побороться с Python за неокрепшие умы, пишущие что-то простое и не собирающиеся в программисты, то, возможно, и сработает, да.
P.P.S. И заметьте, это, видимо, первый доклад на Build, где ни разу не вставили упоминание AI. 😁 Даже удивительно как-то. Хотя вполне можно предположить, что они именно из-за AI у Python'а кусок рынка и собрались откусить. 😉
#csharp #dotnet10
YouTube
No projects just C# with `dotnet run app.cs` | DEM518
Ever wished you could just run some C# without having to think about projects, solutions, or other ceremony? Just create your app.cs file and *run* it? Come learn about new features in the .NET CLI coming in .NET 10 that enable directly running a C# file…
🔥9👍2😱1
Новая SQL Server Management Studio
Несколько дней назад Microsoft таки обновила SQL Server Management Studio.
Предыдущие версии базировались Visual Studio 2017. Т.е. 32-bit и очень плохо с асинхронностью — постоянные мелкие и не очень подвисания, вот это вот всё. На это народ уже просто устал жаловаться.
И вот, наконец-то, SSMS переехала на базу актуальной версии Visual Studio. Будем надеяться, что станет отзывчивее на тяжелых операциях. В остальном функциональность вроде осталась той же.
Сносить 20-ю версию, кстати, не обязательно, новая становится параллельно и, более того, теперь вообще использует инсталлятор Visual Studio.
#базыданных #ssms #microsoft
Несколько дней назад Microsoft таки обновила SQL Server Management Studio.
Предыдущие версии базировались Visual Studio 2017. Т.е. 32-bit и очень плохо с асинхронностью — постоянные мелкие и не очень подвисания, вот это вот всё. На это народ уже просто устал жаловаться.
И вот, наконец-то, SSMS переехала на базу актуальной версии Visual Studio. Будем надеяться, что станет отзывчивее на тяжелых операциях. В остальном функциональность вроде осталась той же.
Сносить 20-ю версию, кстати, не обязательно, новая становится параллельно и, более того, теперь вообще использует инсталлятор Visual Studio.
#базыданных #ssms #microsoft
❤6🔥6
Пятиминутка ненависти
Так. Мне надо выговориться.
Кто у меня учился, тот знает, что я всегда был требователен к следованию стилю оформления кода. Суть сутью, но форма тоже важна. Однако без приведения всех студентов к какому-то одному стилю. В прокрустово ложе именно того стиля, который нравится лично мне, я никого не загонял. Главное — это консистентность. Поэтому я говорил, что можете в этом вопросе сходить с ума любым способом, который вам нравится, но только одним конкретным в рамках одного проекта. Ну, и желательно, чтобы код был по большей части понятен не только вам. А потом в реальных проектах выбора у вас всё равно не будет, будете использовать тот стиль, который принят на проекте.
Реальность, конечно, же ещё жёстче. Людей много, представления о прекрасном у всех свои, и отказыватьсят от них никто по доброй воле не хочет. Поэтому стиль, который принят на проекте, не просто где-то описан, и, если что, правится на code review. Нет, процесс автоматизируется. Не удовлетворишь инструменту проверки стиля — PR не смерджишь. И ладно бы только стиль, он же еще и общие советы по улучшению качества кода дает!
Так вот, у нас используется SonarQube. И как же он меня достаёт иногда. 🤦🏼♂️ Понятно, что всё можно настроить, но, видимо, обычно используются настройки по дефолту, и он порой выступает феерически мелочно и тупо. "У вас целых пять новых строк кода не покрыто тестами, а можно только четыре!". Или "У вас вот эти пять строк повторяются дважды, переделайте, чтобы всюду был DRY!". Я утрирую, конечно, но иногда он просто бесит. 🤬
Я головой понимаю, что, в целом, он проекту помогает. Но эмоционально иногда просто хочется его убить к чертям собачим. 🤬
Всё, пятиминутка ненависти закончена. Спасибо, что выслушали. ❤️ Пойду править его двенадцать очень дельных замечаний. 🤦🏼♂️
#style
Так. Мне надо выговориться.
Кто у меня учился, тот знает, что я всегда был требователен к следованию стилю оформления кода. Суть сутью, но форма тоже важна. Однако без приведения всех студентов к какому-то одному стилю. В прокрустово ложе именно того стиля, который нравится лично мне, я никого не загонял. Главное — это консистентность. Поэтому я говорил, что можете в этом вопросе сходить с ума любым способом, который вам нравится, но только одним конкретным в рамках одного проекта. Ну, и желательно, чтобы код был по большей части понятен не только вам. А потом в реальных проектах выбора у вас всё равно не будет, будете использовать тот стиль, который принят на проекте.
Реальность, конечно, же ещё жёстче. Людей много, представления о прекрасном у всех свои, и отказыватьсят от них никто по доброй воле не хочет. Поэтому стиль, который принят на проекте, не просто где-то описан, и, если что, правится на code review. Нет, процесс автоматизируется. Не удовлетворишь инструменту проверки стиля — PR не смерджишь. И ладно бы только стиль, он же еще и общие советы по улучшению качества кода дает!
Так вот, у нас используется SonarQube. И как же он меня достаёт иногда. 🤦🏼♂️ Понятно, что всё можно настроить, но, видимо, обычно используются настройки по дефолту, и он порой выступает феерически мелочно и тупо. "У вас целых пять новых строк кода не покрыто тестами, а можно только четыре!". Или "У вас вот эти пять строк повторяются дважды, переделайте, чтобы всюду был DRY!". Я утрирую, конечно, но иногда он просто бесит. 🤬
Я головой понимаю, что, в целом, он проекту помогает. Но эмоционально иногда просто хочется его убить к чертям собачим. 🤬
Всё, пятиминутка ненависти закончена. Спасибо, что выслушали. ❤️ Пойду править его двенадцать очень дельных замечаний. 🤦🏼♂️
#style
❤19😁7👍1🔥1
Индийский код
Я тут в живой природе увидел, что такое тот самый «аутсорс в Индию».
У нас одна команд — из Индии. Ну, то есть, как одна. Одна среди команд, которые я знаю, то есть среди тех, кто занимается той же частью нашей системы, что и команда, в которой я. Так что вполне может быть, что далеко не одна. Но вернемся. Команда эта не сейчас появилась, я ее видел на общих митингах с момента прихода в компанию, но сейчас, видимо, ее стали нагружать.
Сначала, я увидел, что такое разница в культуре. Публикуют они PR, синьор из моей команды идет смотреть и пишет замечания. На мой взгляд, вполне по делу. Не много, но есть. И, конечно, она делает это вежливо, местные иначе просто не могут. Так вот, ответы я бы охарактеризовал словом «огрызаться». Я уже отвык от такого, прямо резануло. Они всё исправили, конечно, но прямо пахнуло знакомым до боли хамством.
Дальше — больше. Я увидел, что такое «индийский код». Дали им сделать важный новый микросервис. Не добавить что-то в существующий, а прямо с нуля. А поскольку он важный, то мой тим-лид попросил всех посмотреть, потому что нам потом всем пользоваться его результатами. Так вот, я думал, что «индийский код» — это что-то такое корявое, типа того, что пишут начинающие студенты, там плохо всё, начиная со стиля, и дальше со всеми остановками. Неееет. «Индийский код» — это код, который внешне выглядит более-менее, но начинаешь вчитываться — мамадарагая.
Во-первых, всё выкатили целиком: огромный PR, сиди, разбирайся. Только за первые два дня им написали 70+ замечаний по половине проекта! Попросили их в будущем так не делать, а выкатывать PR'ы вменяемого размера. А во-вторых, всё в кучу. Что такое Clean Architecture хотя бы в общих чертах они знают, но, видимо, не считают важным ему следовать. Про SOLID боюсь спрашивать. До тестов я не дошел, но полагаю, что при таком подходе там сплошная профанация, потому что такой сильно связный код нормально покрыть тестами невозможно. В чисто майкрософтовских делах типа Azure Functions проигнорировали даже best practices от Майкрософта, которые английским по белому в документации прописаны. И всё это не везде, а то там, то тут. Видимо, часть девлоперов в курсе как надо делать, а часть — не очень.
В PR'е с ними были очень вежливы и замечания были по делу. Никакого «ату их». Их тим-лид оказался вменяемым, на все комментарии в этот раз отвечал только он. Видимо, дали понять, что так, как остальные девелоперы общались в прошлый раз — так не надо. Он не огрызался, и они молча исправляли всё, что их просили. В общем, через две с половиной недели PR им заапрувили.
Было прямо интересно за этим всем следить. 😁
#трудовыебудни #культурапрограммирования #психопатологииобыденнойразработки
Я тут в живой природе увидел, что такое тот самый «аутсорс в Индию».
У нас одна команд — из Индии. Ну, то есть, как одна. Одна среди команд, которые я знаю, то есть среди тех, кто занимается той же частью нашей системы, что и команда, в которой я. Так что вполне может быть, что далеко не одна. Но вернемся. Команда эта не сейчас появилась, я ее видел на общих митингах с момента прихода в компанию, но сейчас, видимо, ее стали нагружать.
Сначала, я увидел, что такое разница в культуре. Публикуют они PR, синьор из моей команды идет смотреть и пишет замечания. На мой взгляд, вполне по делу. Не много, но есть. И, конечно, она делает это вежливо, местные иначе просто не могут. Так вот, ответы я бы охарактеризовал словом «огрызаться». Я уже отвык от такого, прямо резануло. Они всё исправили, конечно, но прямо пахнуло знакомым до боли хамством.
Дальше — больше. Я увидел, что такое «индийский код». Дали им сделать важный новый микросервис. Не добавить что-то в существующий, а прямо с нуля. А поскольку он важный, то мой тим-лид попросил всех посмотреть, потому что нам потом всем пользоваться его результатами. Так вот, я думал, что «индийский код» — это что-то такое корявое, типа того, что пишут начинающие студенты, там плохо всё, начиная со стиля, и дальше со всеми остановками. Неееет. «Индийский код» — это код, который внешне выглядит более-менее, но начинаешь вчитываться — мамадарагая.
Во-первых, всё выкатили целиком: огромный PR, сиди, разбирайся. Только за первые два дня им написали 70+ замечаний по половине проекта! Попросили их в будущем так не делать, а выкатывать PR'ы вменяемого размера. А во-вторых, всё в кучу. Что такое Clean Architecture хотя бы в общих чертах они знают, но, видимо, не считают важным ему следовать. Про SOLID боюсь спрашивать. До тестов я не дошел, но полагаю, что при таком подходе там сплошная профанация, потому что такой сильно связный код нормально покрыть тестами невозможно. В чисто майкрософтовских делах типа Azure Functions проигнорировали даже best practices от Майкрософта, которые английским по белому в документации прописаны. И всё это не везде, а то там, то тут. Видимо, часть девлоперов в курсе как надо делать, а часть — не очень.
В PR'е с ними были очень вежливы и замечания были по делу. Никакого «ату их». Их тим-лид оказался вменяемым, на все комментарии в этот раз отвечал только он. Видимо, дали понять, что так, как остальные девелоперы общались в прошлый раз — так не надо. Он не огрызался, и они молча исправляли всё, что их просили. В общем, через две с половиной недели PR им заапрувили.
Было прямо интересно за этим всем следить. 😁
#трудовыебудни #культурапрограммирования #психопатологииобыденнойразработки
😁9🔥4❤1
Bye-bye, Bitbucket
Когда в свое время (да, это было давно, я старый, я знаю 🙂) я знакомился с системами контроля версий и выбирал из них распределенную систему для своих личных задач, я выбрал Mercurial. У него не было индекса (промежуточного слоя между working directory и repository), как в Git, но во всем остальном он был лучше и проще. На рынке тогда между ними был паритет и воевали они не между собой, а с еще весьма популярной тогда централизованной SVN, так что выбор Mercurial'а был вполне вменяемым.
Выбор системы контроля версий — это только половина проблемы. Надо было выбрать и онлайн-сервис хостинга исходников, поддерживающий эту систему контроля версий. Тогда всё было очень просто: из больших сервисов на Git'е был построен GitHub, а на Mercurial'е был построен Bitbucket. Так что после выбора Mercurial'а в качестве системы контроля версий выбор сервиса хостинга был очевиден. На Bitbucket'е я и стал хостить свои проекты и проекты для студентов. И самих студентов к тому же приучил.
Но победив централизованную SVN, распределенные Git и Mercurial сцепились уже между собой. И Git явно начал побеждать. Сначала Bitbucket добавил поддержку Git (при создании нового репозитория вы могли выбрать для него систему контроля версий). А я же все-таки был преподавателем, и учить студентов надо было актуальным и более востребованным вещам, так что я разобрался с Git'ом, перешел на него сам и студентов перевел. Mercurial мне по-прежнему нравился, но чего уж там — эта война была проиграна. Тем более, что, не считая индекса, в Git всё было примерно так же, хоть и он и был сделан Чужими для Хищников. В смысле, Линусом Торвальдсом в первую очередь для себя, и только потом уже для подобных ему разработчиков ядра Linux. Как он сам о себе говорил: «Я пишу на таком странном Си. Результат людям не очень понятен, но мне нравится». Ну, вот и Git до сих пор несет на себе этот же отпечаток руки мастера, хотя сейчас Git, конечно, немного человечнее стал.
Насколько я знаю, из больших компаний только Facebook всё еще сидит на Mercurial и вкладывает в его развитие идеи и деньги. Без него Mercurial бы уже загнулся, а так еще жив. Что, ИМХО, хорошо, пусть цветут все цветы.
Но я отвлекся. Поскольку Bitbucket в тот момент уже поддерживал обе системы контроля версий, то переход на Git не требовал смены сервиса хостинга исходников. К тому же, в тот момент времени Bitbucket бесплатно давал не только публичные, но и приватные репозитории, а GitHub — только публичные. Пару лет назад Bitbucket решил всё-таки закопать стюардессу и прекратил поддержку Mercurial-репозиториев (мне это к тому моменту уже давно было не важно), а GitHub добавил приватные репозитории для всех и даром (а вот это было важно). Но я по-прежнему оставался на Bitbucket'е. До сегодняшнего, блин, дня.
Я не знаю, что там у них вчера вечером и сегодня утром происходило, но работал он через... Хреново, в общем, работал. И что-то я сломался. Перенес и публичные, и, главное, приватные репозитории на GitHub. Ну, потому что всё, хватит. Теперь моя очередь закапывать стюардессу.
Спасибо, Bitbucket, это была славная охота, но прощай.
#vcs #git #mercurial #hg #bitbucket #github
Когда в свое время (да, это было давно, я старый, я знаю 🙂) я знакомился с системами контроля версий и выбирал из них распределенную систему для своих личных задач, я выбрал Mercurial. У него не было индекса (промежуточного слоя между working directory и repository), как в Git, но во всем остальном он был лучше и проще. На рынке тогда между ними был паритет и воевали они не между собой, а с еще весьма популярной тогда централизованной SVN, так что выбор Mercurial'а был вполне вменяемым.
Выбор системы контроля версий — это только половина проблемы. Надо было выбрать и онлайн-сервис хостинга исходников, поддерживающий эту систему контроля версий. Тогда всё было очень просто: из больших сервисов на Git'е был построен GitHub, а на Mercurial'е был построен Bitbucket. Так что после выбора Mercurial'а в качестве системы контроля версий выбор сервиса хостинга был очевиден. На Bitbucket'е я и стал хостить свои проекты и проекты для студентов. И самих студентов к тому же приучил.
Но победив централизованную SVN, распределенные Git и Mercurial сцепились уже между собой. И Git явно начал побеждать. Сначала Bitbucket добавил поддержку Git (при создании нового репозитория вы могли выбрать для него систему контроля версий). А я же все-таки был преподавателем, и учить студентов надо было актуальным и более востребованным вещам, так что я разобрался с Git'ом, перешел на него сам и студентов перевел. Mercurial мне по-прежнему нравился, но чего уж там — эта война была проиграна. Тем более, что, не считая индекса, в Git всё было примерно так же, хоть и он и был сделан Чужими для Хищников. В смысле, Линусом Торвальдсом в первую очередь для себя, и только потом уже для подобных ему разработчиков ядра Linux. Как он сам о себе говорил: «Я пишу на таком странном Си. Результат людям не очень понятен, но мне нравится». Ну, вот и Git до сих пор несет на себе этот же отпечаток руки мастера, хотя сейчас Git, конечно, немного человечнее стал.
Насколько я знаю, из больших компаний только Facebook всё еще сидит на Mercurial и вкладывает в его развитие идеи и деньги. Без него Mercurial бы уже загнулся, а так еще жив. Что, ИМХО, хорошо, пусть цветут все цветы.
Но я отвлекся. Поскольку Bitbucket в тот момент уже поддерживал обе системы контроля версий, то переход на Git не требовал смены сервиса хостинга исходников. К тому же, в тот момент времени Bitbucket бесплатно давал не только публичные, но и приватные репозитории, а GitHub — только публичные. Пару лет назад Bitbucket решил всё-таки закопать стюардессу и прекратил поддержку Mercurial-репозиториев (мне это к тому моменту уже давно было не важно), а GitHub добавил приватные репозитории для всех и даром (а вот это было важно). Но я по-прежнему оставался на Bitbucket'е. До сегодняшнего, блин, дня.
Я не знаю, что там у них вчера вечером и сегодня утром происходило, но работал он через... Хреново, в общем, работал. И что-то я сломался. Перенес и публичные, и, главное, приватные репозитории на GitHub. Ну, потому что всё, хватит. Теперь моя очередь закапывать стюардессу.
Спасибо, Bitbucket, это была славная охота, но прощай.
#vcs #git #mercurial #hg #bitbucket #github
❤🔥13😭3👍1
Скоро на экранах: .NET 10
Грядет ноябрь, а с ним и .NET 10, и Стивен Тауб разразился еще одним монструозным постом в своем стиле в официальном блоге (читать это всё нет никаких сил, но можно пролистать) про улучшения перформанса, которые наш ждут. Хорошо улучшили, особенно LINQ (там до 100% до 1000% прирост скорости на некоторых операциях и от 50% до той же 1000% уменьшение аллокаций).
«Десятка» будет LTS-релизом, так что понятно, почему упор на оптимизации, а не на фичах. Фичи будут через год в .NET 11. Может, это даже будут discriminated unions в C#. Не обещают, что прямо будет или что будет целиком, но спецификацию опубликовали и сказали, что работают над ними.
Visual Studio 2026 тоже будет в ноябре. В целом, всё то же, но будет некоторое обновление визуального стиля. Судя по скриншотам — в лучшую сторону. Главное, чтобы мою любимую стандартную тему Blue не испортили, а то были уже прецеденты. 😡
Ну, поглядим. 🤔
#dotnet #csharp #visualstudio
Грядет ноябрь, а с ним и .NET 10, и Стивен Тауб разразился еще одним монструозным постом в своем стиле в официальном блоге (читать это всё нет никаких сил, но можно пролистать) про улучшения перформанса, которые наш ждут. Хорошо улучшили, особенно LINQ (там до 100% до 1000% прирост скорости на некоторых операциях и от 50% до той же 1000% уменьшение аллокаций).
«Десятка» будет LTS-релизом, так что понятно, почему упор на оптимизации, а не на фичах. Фичи будут через год в .NET 11. Может, это даже будут discriminated unions в C#. Не обещают, что прямо будет или что будет целиком, но спецификацию опубликовали и сказали, что работают над ними.
Visual Studio 2026 тоже будет в ноябре. В целом, всё то же, но будет некоторое обновление визуального стиля. Судя по скриншотам — в лучшую сторону. Главное, чтобы мою любимую стандартную тему Blue не испортили, а то были уже прецеденты. 😡
Ну, поглядим. 🤔
#dotnet #csharp #visualstudio
Microsoft News
Performance Improvements in .NET 10
Take a tour through hundreds of performance improvements in .NET 10.
❤🔥6❤1🔥1
Индийский код, часть 2
История с индийской командой потихоньку продолжается. 🙂
Выкатили они еще один PR. Качество в этот раз нормальное, получили несколько комментариев, но ничего серьезного. Но! PR опять дикого размера. А ведь их просили.
Наблюдаю у моего тимлида по этому поводу... эм-м-м... некоторое недоумение. 🙂 Ибо просили же уже один раз. Есть у меня подозрение, что у остальных британских тимлидов нашей части проекта примерно такое же недоумение. Интересное будет, когда оно дойдет до менеджера, который над нашими тимлидами.
«Ну, ничего, мы подождем» (с). 😁
#трудовыебудни #культурапрограммирования #психопатологииобыденнойразработки
История с индийской командой потихоньку продолжается. 🙂
Выкатили они еще один PR. Качество в этот раз нормальное, получили несколько комментариев, но ничего серьезного. Но! PR опять дикого размера. А ведь их просили.
Наблюдаю у моего тимлида по этому поводу... эм-м-м... некоторое недоумение. 🙂 Ибо просили же уже один раз. Есть у меня подозрение, что у остальных британских тимлидов нашей части проекта примерно такое же недоумение. Интересное будет, когда оно дойдет до менеджера, который над нашими тимлидами.
«Ну, ничего, мы подождем» (с). 😁
#трудовыебудни #культурапрограммирования #психопатологииобыденнойразработки
😁10
День программиста 😎
Да, 256-ой (2^8) день в году, все таки.
С профессиональным праздником нас, коллеги! Пусть по-прежнему будет интересно всем этим заниматься, не смотря ни на что! 😉🤝🥳
#devsarenotagame #программистыэтонеигра
Да, 256-ой (2^8) день в году, все таки.
С профессиональным праздником нас, коллеги! Пусть по-прежнему будет интересно всем этим заниматься, не смотря ни на что! 😉🤝🥳
#devsarenotagame #программистыэтонеигра
🍾23❤2❤🔥1
Шутки SQL Server Management Studio
Заводит наша QA баг, в котором пишет, что одно достаточно длинное текстовое поле (
И таки да, обрезается. Но очень как-то подозрительно обрезается — ровно до 64КБ. Проверяю отладчиком в нашем коде — неа, всё в порядке, в БД всё правильно хранится и нашим кодом правильно считывается. Значит, думаю, дело в SSMS.
Пошел гуглить и выяснилось, что действительно, это SSMS обрезает при чтении. Причем, это не баг, а фича — это специально сделано и прямо в настройках запроса регулируется (см. скриншот). Здравый смысл в этом, конечно, есть, но я просто первый раз в этим столкнулся, потому что у меня таких длинный полей раньше не было.
Блин, Microsoft, предупреждать же надо. 🤦🏻♂️
#microsoft #ssms #databases
Заводит наша QA баг, в котором пишет, что одно достаточно длинное текстовое поле (
nvarchar(max)) в нашей БД обрезается. Ладно, запустил SSMS и пошел смотреть.И таки да, обрезается. Но очень как-то подозрительно обрезается — ровно до 64КБ. Проверяю отладчиком в нашем коде — неа, всё в порядке, в БД всё правильно хранится и нашим кодом правильно считывается. Значит, думаю, дело в SSMS.
Пошел гуглить и выяснилось, что действительно, это SSMS обрезает при чтении. Причем, это не баг, а фича — это специально сделано и прямо в настройках запроса регулируется (см. скриншот). Здравый смысл в этом, конечно, есть, но я просто первый раз в этим столкнулся, потому что у меня таких длинный полей раньше не было.
Блин, Microsoft, предупреждать же надо. 🤦🏻♂️
#microsoft #ssms #databases
😁11✍2👨💻1