Программисты — это не игра

День программиста 😎Да, 256-ой (2^8) день в году, все таки.С профессиональным праздником нас, коллеги! Пусть по-прежнему будет интересно всем этим заниматься, не смотря ни на что! 😉🤝🥳#devsarenotagame #программистыэтонеигра

Индийский код, часть 2История с индийской командой потихоньку продолжается. 🙂Выкатили они еще один PR. Качество в этот раз нормальное, получили несколько комментариев, но ничего серьезного. Но! PR опять дикого размера. А ведь их просили.Наблюдаю у моего тимлида по этому поводу... эм-м-м... некоторое недоумение. 🙂 Ибо просили же уже один раз. Есть у меня подозрение, что у остальных британских тимлидов нашей части проекта примерно такое же недоумение. Интересное будет, когда оно дойдет до менеджера, который над нашими тимлидами.«Ну, ничего, мы подождем» (с). 😁#трудовыебудни #культурапрограммирования #психопатологииобыденнойразработки

Скоро на экранах: .NET 10Грядет ноябрь, а с ним и .NET 10, и Стивен Тауб разразился еще одним монструозным постом в своем стиле в официальном блоге (читать это всё нет никаких сил, но можно пролистать) про улучшения перформанса, которые наш ждут. Хорошо улучшили, особенно LINQ (там до 100% до 1000% прирост скорости на некоторых операциях и от 50% до той же 1000% уменьшение аллокаций).«Десятка» будет LTS-релизом, так что понятно, почему упор на оптимизации, а не на фичах. Фичи будут через год в .NET 11. Может, это даже будут discriminated unions в C#. Не обещают, что прямо будет или что будет целиком, но спецификацию опубликовали и сказали, что работают над ними.Visual Studio 2026 тоже будет в ноябре. В целом, всё то же, но будет некоторое обновление визуального стиля. Судя по скриншотам — в лучшую сторону. Главное, чтобы мою любимую стандартную тему Blue не испортили, а то были уже прецеденты. 😡Ну, поглядим. 🤔#dotnet #csharp #visualstudio

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, конечно, немного человечнее стал.Насколько я знаю, из больших компаний

Индийский кодЯ тут в живой природе увидел, что такое тот самый «аутсорс в Индию».У нас одна команд — из Индии. Ну, то есть, как одна. Одна среди команд, которые я знаю, то есть среди тех, кто занимается той же частью нашей системы, что и команда, в которой я. Так что вполне может быть, что далеко не одна. Но вернемся. Команда эта не сейчас появилась, я ее видел на общих митингах с момента прихода в компанию, но сейчас, видимо, ее стали нагружать.Сначала, я увидел, что такое разница в культуре. Публикуют они PR, синьор из моей команды идет смотреть и пишет замечания. На мой взгляд, вполне по делу. Не много, но есть. И, конечно, она делает это вежливо, местные иначе просто не могут. Так вот, ответы я бы охарактеризовал словом «огрызаться». Я уже отвык от такого, прямо резануло. Они всё исправили, конечно, но прямо пахнуло знакомым до боли хамством.Дальше — больше. Я увидел, что такое «индийский код». Дали им сделать важный новый микросервис. Не добавить что-то в существующий, а прямо с нуля. А поскольку он важный, то мой тим-лид попросил всех посмотреть, потому что нам потом всем пользоваться его результатами. Так вот, я думал, что «индийский код» — это что-то такое корявое, типа того, что пишут начинающие студенты, там плохо всё, начиная со стиля, и дальше со всеми остановками. Неееет. «Индийский код» — это код, который внешне выглядит более-менее, но начинаешь вчитываться — мамадарагая.Во-первых, всё выкатили целиком: огромный PR, сиди, разбирайся. Только за первые два дня им написали 70+ замечаний по половине проекта! Попросили их в будущем так не делать, а выкатывать PR'ы вменяемого размера. А во-вторых, всё в кучу. Что такое Clean Architecture хотя бы в общих чертах они знают, но, видимо, не считают важным ему следовать. Про SOLID боюсь спрашивать. До тестов я не дошел, но полагаю, что при таком подходе там сплошная профанация, потому что такой сильно связный код нормально покрыть тестами невозможно. В чисто майкрософтовских делах типа Azure Functions проигнориро

Пятиминутка ненавистиТак. Мне надо выговориться.Кто у меня учился, тот знает, что я всегда был требователен к следованию стилю оформления кода. Суть сутью, но форма тоже важна. Однако без приведения всех студентов к какому-то одному стилю. В прокрустово ложе именно того стиля, который нравится лично мне, я никого не загонял. Главное — это консистентность. Поэтому я говорил, что можете в этом вопросе сходить с ума любым способом, который вам нравится, но только одним конкретным в рамках одного проекта. Ну, и желательно, чтобы код был по большей части понятен не только вам. А потом в реальных проектах выбора у вас всё равно не будет, будете использовать тот стиль, который принят на проекте.Реальность, конечно, же ещё жёстче. Людей много, представления о прекрасном у всех свои, и отказыватьсят от них никто по доброй воле не хочет. Поэтому стиль, который принят на проекте, не просто где-то описан, и, если что, правится на code review. Нет, процесс автоматизируется. Не удовлетворишь инструменту проверки стиля — PR не смерджишь. И ладно бы только стиль, он же еще и общие советы по улучшению качества кода дает!Так вот, у нас используется SonarQube. И как же он меня достаёт иногда. 🤦🏼‍♂️ Понятно, что всё можно настроить, но, видимо, обычно используются настройки по дефолту, и он порой выступает феерически мелочно и тупо. "У вас целых пять новых строк кода не покрыто тестами, а можно только четыре!". Или "У вас вот эти пять строк повторяются дважды, переделайте, чтобы всюду был DRY!". Я утрирую, конечно, но иногда он просто бесит. 🤬Я головой понимаю, что, в целом, он проекту помогает. Но эмоционально иногда просто хочется его убить к чертям собачим. 🤬Всё, пятиминутка ненависти закончена. Спасибо, что выслушали. ❤️ Пойду править его двенадцать очень дельных замечаний. 🤦🏼‍♂️#style

Новая SQL Server Management StudioНесколько дней назад Microsoft таки обновила SQL Server Management Studio.Предыдущие версии базировались Visual Studio 2017. Т.е. 32-bit и очень плохо с асинхронностью — постоянные мелкие и не очень подвисания, вот это вот всё. На это народ уже просто устал жаловаться.И вот, наконец-то, SSMS переехала на базу актуальной версии Visual Studio. Будем надеяться, что станет отзывчивее на тяжелых операциях. В остальном функциональность вроде осталась той же.Сносить 20-ю версию, кстати, не обязательно, новая становится параллельно и, более того, теперь вообще использует инсталлятор Visual Studio.#базыданных #ssms #microsoft

Хорошая новость с Build'аНу, наконец-то. Начиная с .NET 10 на C# можно будет писать скрипты: https://www.youtube.com/watch?v=98MizuB7i-w. Ну, т.е что угодно, не обязательно только скрипты в классическом понимании, можно хоть API-сервис так поднять (в видео, кстати, это тоже есть), но понятно, что если нужна простенькая программка в одном cs-файле, то на какую-то мегафунциональность мы по-любому не замахиваемся.Ни файла проекта, ничего не нужно, только cs-файл:dotnet run script.csА под Линуксом так вообще #!: поддерживается, прямо как в лучших домах Ландона:#!/usr/bin/dotnet runConsole.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

Маленькие радости .NET-разработчикаВы не поверите, но в 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, которого в L

Тут годноту подвезлиСережа Гречко, один из моих тимлидов, у которого я очень многому научился (в первую очередь — взгляду на профессию как на инженерную дисциплину), завел свой YouTube-канал. Там много Linux'а и его тулинга, но главное — много сути происходящего, что, на мой взгляд, будет полезно и тем, кто работает с Windows. Так что очень рекомендую.#youtube #softwareengineering