Илюшёво

А как вы проверяете SSD после покупки? Я вот даже целую инструкцию выкладывал в 2023 году по утилитке h2testw. Выпуск, вообще, настолько годный оказался, что его наверное и в 2030-м году можно будет пересмотреть... с интересом. Но, новость не об этом. Тут парни, которые занимаются разработкой CrystalDiskInfo, начиная с версии 9.9.0 добавили в свою утилитку простой определитель фейковых SSD Samsung! h2testw это годнота и пользоваться ей можно и нужно, но занимает время. А тут подключил SSD, запустил софтину и сразу результат, без долгих десятков минут ожидания.

"Вредительская" - хранилище кода со всего мира, откуда киздят 100% уже написанного кода. 🤔 Блокировка GitHub может скоро произойти в России — в Госдуме назвали площадку «вредительской» и призвали отказаться от неё Зампред IT-комитета Антон Горелкин призвал российских разработчиков срочно уходить с крупнейшего сервиса для хостинга IT-проектов GitHub, обвинив Microsoft в целенаправленном ухудшении доступа к сервису для пользователей из России По его словам, число сбоев при подключении уже держится на уровне около 16%, а в будущем ситуация может стать ещё хуже и вскоре достигнет 100%. Горелкин считает, что зависимость от американских IT-платформ пора прекращать, переходя на отечественные аналоги, которых полно в стране Депутат также предрёк неизбежную фрагментацию интернет-пространства — он считает, что опыт Китая по созданию собственных локальных сервисов просто опередил своё время.

В СССР программировали не спеша. С какой-то иронией. А джунами топили печи или закатывали их в банки

Очередная новость про Max оказалась фейком - официальная позиция разработчиков. Ранее были публикации в TG-каналах, с предположениями, что Мах якобы имеет доступ к расшифровке разговоров пользователей на основании обнаруженного в Max ИИ-инструмента, который запрограммирован реагировать на кодовую фразу вида "не слышу / плохо слышу". Пользователи начали предполагать, что ИИ в Max может перехватывать и другие кодовые фразы или сможет делать это после очередного обновления. Новость быстро завирусилась и ее прокомментировали разработчики Max. "Технологии звонков в Мах используют машинное обучение для анализа условий связи и автоматической подстройки параметров звонка. Так система понимает, когда качество падает ниже критического уровня, чтобы переключить сервер или кодек", - пояснили в центре безопасности Max. Таким образом, официальная позиция разработчиков - новость фейк. Все разговоры в Мах зашифрованы, данные пользователей надежно защищены.

Вот так вот, разработчики не понимают ничего. Пипл схавает

Обосранцы VK-вские. Кто решил, что вк надо отдать "право" на "создание" национального "мессенджера" (прим. Прослушивающего и записывающего приложения, для компрометации вашего всего с телефона до прабабушки в режиме live с использованием AI) https://pikabu.ru/story/chto_skryivaet_max_2_v_messendzher_vstroena_sistema_raspoznavaniya_klyuchevyikh_slov_vo_vremya_zvonkov_13876232

😁😆😁 не знаю что это и зачем, но пусть будет Update: оказался скам на казик. Будьте внимательны ⚠️

Вторая часть моей серии статей по специям: имбирь. Имбирь(основные действующие вещества имбиря: фенольные соединения шогаол и гингерол, а так же парадол). Имбирь – это растение-многолетник с горизонтально залегающим толстым корнем, который используют как…

Clean Architecture: что оставить, что выбросить #cleanarchitecture #bestpractices #devnotes Clean Architecture — это не “4 кольца и 10 проектов”, а пара идей, которые реально помогают. Остальное часто превращается в ритуалы и оверинжиниринг. Что оставить ✅ 1️⃣ Правило зависимостей (Dependency Rule) Зависимости должны идти внутрь: домен/юзкейсы не зависят от ASP.NET Core, EF Core, Serilog, MediatR. Это значит: • бизнес-правила и use cases — без ссылок на инфраструктуру, • наружу — через интерфейсы/порты, реализации — в Infrastructure. 2️⃣ Use cases в центре Храним логику вокруг сценариев (CreateOrder, CancelSubscription), а не вокруг “сервисов ради сервисов”. Use case = оркестрация, домен = инварианты. 3️⃣ Границы и контракты DTO из API ≠ доменные модели. Явно разделяем: • Web: request/response DTO • Application: команды/результаты • Domain: сущности/VO 4️⃣ Тестируемость Если use cases зависят от интерфейсов (IClock, IOrderRepository) — тесты быстрые и простые. Что выбросить ❌ 1️⃣ Слои ради слоёв Controller → Service → Manager → Handler → … и всё просто “прокидывает параметры”. Если слой не даёт ценности (валидация/оркестрация/транзакции/политики) — он лишний. 2️⃣ Generic Repository + Unit of Work поверх EF Core EF Core уже DbSet/DbContext. Универсальные репозитории часто убивают LINQ и плодят бойлерплейт. Если нужен репозиторий — делайте специфичный под агрегат/сценарий. 3️⃣ Микропроекты на каждый чих “Domain/Application/Infrastructure/Web/Shared/Common/Kernel…” ради CRUD — дорого для изменений и онбординга. Часто достаточно 2–4 проектов или даже одного решения с модулями. 4️⃣ “Чистый домен” без домена Если домен — просто свойства, а правила живут в “сервисах”, CA становится декорацией. Практичная схема для .NET • Web/API: endpoints, DTO, auth • Application: use cases (commands/queries), валидация, транзакции/поведения • Domain: сущности, value objects, инварианты • Infrastructure: EF Core, интеграции, реализации портов Главное: Application/Domain не знают про EF и HTTP. Мини-чеклист: “Оставить/выбросить” ✅ Оставить: • Dependency Rule • Use cases как центр • Явные границы (DTO vs domain) • Тестируемость через порты • Локальные решения под контекст (а не догму) ❌ Выбросить: • слои без смысла • generic repository поверх EF • 10 проектов ради CRUD • AutoMapper как религию • архитектуру “на вырост”, когда вы ещё не выросли @aStateOfNet

Использование валидаторов https://habr.com/ru/articles/1010654

Большинство разработчиков могут назвать 10 типов тестирования. Но лишь немногие могут объяснить, когда использовать каждый из них. Вот краткий разбор: 1. Smoke Testing (смоук-тестирование) Приложение вообще запускается? 2. Functional Testing (функциональное тестирование) Каждая функция возвращает корректный результат? 3. Integration Testing (интеграционное тестирование) Модули продолжают работать корректно, когда они соединены между собой? 4. Regression Testing (регрессионное тестирование) Последний коммит не сломал то, что ещё вчера работало? 5. Load Testing (нагрузочное тестирование) Система справляется с реальным трафиком без «захлёбывания»? 6. Stress Testing (стресс-тестирование) Что произойдёт, если нагрузку довести до предела? 7. Security Testing (тестирование безопасности) Может ли кто-то воспользоваться уязвимостью, о которой вы не знали? 8. UI Testing (тестирование пользовательского интерфейса) Интерфейс ведёт себя так, как ожидает пользователь? 9. Fuzz Testing (фазз-тестирование) Что сломается, если отправлять приложению случайные или некорректные данные? 10. Reliability Testing (тестирование надёжности) Система остаётся стабильной после работы в течение дней, а не минут? 👉 @KodBlog

Офигительное исследование автоматизации #HR и исследования рынка труда корпорациями опубликовал Питер Гирнус. Как компании и их топы зарабатывают реальные деньги массово публикуя фейковые вакансии. Я конечно знал и ранее, что там такое же тотальное наебалово, что и рынке рекламы или в финансах. Но всё равно охренел. Бигдата+обман работают лучше вместе, чем по отдельности. Полный текст по ссылке в конце, а тут просто перевёл к нему предисловие, написанное якобы от имени корпоративного HR-босса: В прошлом году я разместил 500 открытых вакансий для своей компании. Мы наняли 34 человека. Остальные 466 вакансий никогда не были настоящими. Я — руководитель отдела подбора персонала. Но подбираю я не персонал. Я подбираю данные. Резюме, зарплатные ожидания, наборы навыков, рыночную аналитику. 160 000 соискателей бесплатно отдали нам свою карьерную историю. Мы использовали её для бенчмаркинга компенсаций. Не чтобы поднять зарплаты. Чтобы убедиться, что мы платим ниже рынка, и продолжать это делать. Я называю это «формирование кадрового резерва». Кадровый резерв — это то, что формируешь и никогда не используешь. Рекрутеры называют это «пассивным сорсингом». Нет ничего пассивного в том, чтобы тратить время 160 000 человек. Но звучит как стратегия. Некоторые наши вакансии висят уже 11 месяцев. Одна — уже два года. «Директор по инновациям». У нас нет отдела инноваций. У нас нет бюджета. Но вакансия создаёт впечатление, что мы растём. Инвесторы видят открытые позиции и думают — динамика. Наши акции выросли на 8% после того, как мы за одну неделю выложили 200 вакансий. На той неделе мы никого не наняли. И на следующей тоже. У нас есть система отслеживания кандидатов. Она автоматически отклоняет 95% соискателей. По ключевым словам. Каким именно — я не знаю. Никто не знает. Её настроил в 2019 году подрядчик, который у нас больше не работает. Мы её ни разу не обновляли. Некоторые соискатели часами подгоняют свои резюме. Система читает их шесть секунд. А потом отправляет письмо с отказом. «После тщательного рассмотрения». Никакого рассмотрения не было. Ни тщательного, ни какого-либо другого. Я это знаю, потому что шаблон писал я. Иногда я перепубликую ту же вакансию с другим названием. «Старший аналитик данных» превращается в «Ведущий аналитик по данным». То же описание. Та же зарплата. Так же никого не нанимают. Но дата публикации обнуляется. Свежие объявления привлекают больше откликов. Больше откликов — больше данных. Больше данных — лучше бенчмаркинг. Лучше бенчмаркинг — я выступаю на квартальном ревью. В прошлом квартале я выступал. Показал слайд: «беспрецедентный интерес со стороны кандидатов». 160 000 человек откликнулись на вакансии, которых не существовало. Вот он, беспрецедентный интерес. Вице-президент по персоналу назвала это «силой бренда». Финансовый директор спросил про эффективность найма. Я сказал, что мы «оптимизируем качество, а не скорость». Качество означает — мы никого не наняли. Скорость означает — и не собираемся. HR спросил про кандидатский опыт. Я показал им наш NPS. 12. Из 100. Я сказал, что это «в пределах отраслевой нормы». Отраслевую норму я выдумал. Никто не проверил. Никогда не проверяют. В прошлом месяце мне написала кандидатка напрямую. Сказала, что за восемь месяцев откликнулась на четыре наши вакансии. Каждый раз адаптировала резюме. Каждый раз писала сопроводительное. Ни разу не получила ответа. Она спросила, настоящие ли вакансии. Я отправил её на автоматический FAQ. В FAQ написано: «Мы ценим каждый отклик». Это неправда. Мы ценим каждую точку данных. Это разные вещи. Меня ждёт повышение. Мои метрики выдающиеся. 500 вакансий размещено. 160 000 кандидатов собрано. Стоимость привлечения: $0. Я никого не привлёк. Но стоимость — ноль. Ноль — хорошее число на дашборде. Дашборды показывают на презентациях. Презентации утверждают. Утверждения приводят к повышению. К четвёртому кварталу я стану вице-президентом по талантам. Я не нахожу таланты. Я их коллекционирую. Как банку, которую никогда не откроешь.​​​​​​​​​​​​​​​​ https://x.com/gothburz/status/2031109663874494773?s=46

Собрал проект для базовой настройки и базового конфига для кафки. Без архитектуры, без слоев и прочего. Чистое решение для наглядности https://github.com/IKalentsov/Kafka_Learn #kafka #solution

6 Шагов для Правильной Настройки Нового .NET-проекта 1. Задай единый стиль кода Первое, что я добавляю в проект — файл .editorconfig. Он заставляет всех в команде придерживаться одинакового форматирования и соглашений об именах, чтобы не было разношерстных отступов и случайных неймингов. Создать его можно прямо в Visual Studio. Стандартная конфигурация - хороший старт, но можно подстроить под вкусы команды. Положи файл в корень решения, чтобы все проекты следовали тем же правилам. При желании можно переопределить настройки в отдельных подпапках, добавив туда свой .editorconfig. Вот два примера .editorconfig, которые можно использовать: - из репозитория .NET runtime - вариант для обычных .NET-проектов 2. Централизуй настройки сборки Дальше я добавляю файл Directory.Build.props в корень решения. Он позволяет задавать настройки сборки, общие для всех проектов. Пример: <Project> <PropertyGroup> <TargetFramework>net10.0</TargetFramework> <ImplicitUsings>enable</ImplicitUsings> <Nullable>enable</Nullable> <TreatWarningsAsErrors>true</TreatWarningsAsErrors> </PropertyGroup> </Project> Так .csproj файлы остаются чистыми и единообразными, поэтому не нужно повторять эти свойства в каждом проекте. Если потом захочешь подключить статические анализаторы или поменять параметры сборки, то делается это в одном месте. Фишка в том, что .csproj файлы становятся почти пустыми, кроме ссылок на NuGet-пакеты. 3. Централизуй управление пакетами Когда решение разрастается, версии NuGet-пакетов в разных проектах начинают расходиться и чёрт, это превращается в кошмар 😬 Тут помогает централизованное управление пакетами. Создай в корне файл Directory.Packages.props: <Project> <PropertyGroup> <ManagePackageVersionsCentrally>true</ManagePackageVersionsCentrally> </PropertyGroup> <ItemGroup> <PackageVersion Include="Microsoft.AspNetCore.OpenApi" Version="10.0.0" /> <PackageVersion Include="SonarAnalyzer.CSharp" Version="10.15.0.120848" /> </ItemGroup> </Project> Теперь, когда подключаешь пакет в проекте, указываешь только имя, без версии: <PackageReference Include="Microsoft.AspNetCore.OpenApi" /> Все версии хранятся централизованно. Обновлять зависимости становится проще, а рассинхрон версий между проектами исчезает. Если нужно, можно переопределить версию в конкретном проекте. 4. Подключи статический анализ кода Статический анализ помогает ловить потенциальные баги и следить за качеством кода. В .NET уже есть встроенные анализаторы, но я обычно добавляю SonarAnalyzer.CSharp, ведь он делает проверку глубже. Установи пакет: Install-Package SonarAnalyzer.CSharp И добавь его как глобальную зависимость в Directory.Build.props: <ItemGroup> <PackageReference Include="SonarAnalyzer.CSharp" /> </ItemGroup> Дополнительно настрой сборку: <Project> <PropertyGroup> <TreatWarningsAsErrors>true</TreatWarningsAsErrors> <AnalysisLevel>latest</AnalysisLevel> <AnalysisMode>All</AnalysisMode> <CodeAnalysisTreatWarningsAsErrors>true</CodeAnalysisTreatWarningsAsErrors> <EnforceCodeStyleInBuild>true</EnforceCodeStyleInBuild> </PropertyGroup> </Project> Теперь билд упадет, если будут серьезные проблемы с качеством кода = неплохая страховка. Если какие-то правила не подходят, можно понизить их уровень до none в .editorconfig. 5. Настрой локальную оркестрацию Чтобы у всех разработчиков среда была одинаковой, стоит настроить контейнерную оркестрацию. Один из вариантов это .NET Aspire .NET Aspire добавляет сервис-дискавери, телеметрию и упрощает конфигурацию. Все это встроено прямо в .NET-проекты. Пример добавления проекта и Postgres-ресурса: var postgres = builder.AddPostgres("demo-db"); builder.AddProject<WebApi>("webapi") .WithReference(postgres) .WaitFor(postgres); builder.Build().Run(); Aspire под капотом использует Docker, но разработчику с ним работать приятнее. В любом случае цель одна. 6. Автоматизируй сборку через CI В конце я настраиваю простой workflow в GitHub Actions, чтобы проверять каждый коммит. 👉 @KodBlog

Классная подборка расширений для удобства разработки https://toolbox.bitspire.ch/home

Конфигурация параметров проекта через FluentValidations. Помимо удобной регистрации зависимостей и регистрации сервисов в каждой из сборок через класс DependencyInjection позволяет накрутить проверку во время старта корректности путей, плюс пример тестов для локальной проверки без запуска проекта. https://www.milanjovanovic.tech/blog/options-pattern-validation-in-aspnetcore-with-fluentvalidation?utm_source=X&utm_medium=social&utm_campaign=05.01.2026

Чистая архитектура. Статья про разбиение на слои, и управление зависимостями с разными подходами. https://www.milanjovanovic.tech/blog/clean-architecture-the-missing-chapter?utm_source=X&utm_medium=social&utm_campaign=28.04.2025

Вышла 10-ка https://habr.com/ru/companies/pvs-studio/articles/965160/