• Я растерял веру в разработку, выгорел, но меня спас культ инструмента
    +3
    Но есть и минусы, самый большой связан с C# :) Он (C#) настолько хорош, то убедить бизнесы переходить с него — прям таки адски сложная задача. Стоит ли?

    Долго для самого себя искал аргументы, чтобы перейти с C# на F# в продакшн, но не нашел достаточного количества. Какие факторы стали решающими для вас?
  • В Госдуму внесен законопроект об автономной работе рунета
    +1

    Пока читал комментарии мозг как-то сам придумал сценарий для фильма в жанре отечественного кибер-панка. 2045 год. В России введён железный занавес, доступа к интернету нет, есть только внутренняя сеть в стране. Доступ к сети осуществляется с помощью вживлённых чипов. Весь трафик согласно 5 поправке к священному пакету Яровой хранится бессрочно. Последняя надежда — распределенное кибер-подполье, использующее дронов для подключения к спутниковому интернету. Главный герой — молодой сотрудник кибер отдела ФСБ — Игнат. Во время очередного задания он влюбляется в юную участницу сопротивления — Ольгу. Ольга показывает Игнату информацию из настоящего интернета и Игнат решает стать двойным агентом на стороне подполья. Теперь им предстоит найти легендарного хакера. Хакер должен помочь обойти защиту и опубликовать информацию из мирового интернета в чебурнете. В 2020 он уже взломал правительственные сервера и опубликовал секретную информацию в тогда еще открытом интернете. После этого никто больше о нем ничего не слышал… до сегодняшнего дня. Героям предстоит путешествие в Сибирскую тайгу.

  • В Госдуму внесен законопроект об автономной работе рунета
    +3

    Пока читал комментарии мозг как-то сам придумал сценарий для фильма в жанре отечественного кибер-панка. 2045 год. В России введён железный занавес, доступа к интернету нет, есть только внутренняя сеть в стране. Доступ к сети осуществляется с помощью вживлённых чипов. Весь трафик согласно 5 поправке к священному пакету Яровой хранится бессрочно. Последняя надежда — распределенное кибер-подполье, использующее дронов для подключения к спутниковому интернету. Главный герой — молодой сотрудник кибер отдела ФСБ — Игнат. Во время очередного задания он влюбляется в юную хакерские Ольгу. Ольга показывает Игнату информацию из настоящего интернета и Игнат решает стать двойным агентом на стороне подполья. Теперь им предстоит найти легендарного хакера. Хакер должен помочь обойти защиту и опубликовать информацию из мирового интернета в чебурнете. В 2020 он уже взломал правительственные сервера и опубликовал секретную информацию в тогда еще открытом интернете. После этого никто больше о нем ничего не слышал… до сегодняшнего дня. Героям предстоит путешествие в Сибирскую тайгу.

  • Сущности в DDD-стиле с Entity Framework Core
    0
    А если для инициализации агрегата потребуется over 20 параметров. Делать конструктор с кучей параметров?

    Значит это какой-то неправильный агрегат и делает неправильный мед, в том смысле, что не хватает какие-то дополнительных сущностей. За 10 лет ни разу не пришлось даже 10 параметров в конструктор передать.

    И что делать если логика должна предполагать как полную так и частичную инициализацию агрегата?

    Частичная инициализации сущности — анти-паттерн. Еслу нужно работать с драфтами, добавьте соответствующие ValueObject'ы по одному на каждый кейс частичной инициализации.
  • Сущности в DDD-стиле с Entity Framework Core
    0
    Если данные можно менять по отдельности / вместе в любых комбинациях и это не на что не влияет, оставляйте все публичным. Но если это действительно можно делать, то в вашем приложении просто нет никакой бизнес-логики и DDD не нужен.
  • Иди-ка ты на !@# со своей «токсичностью»
    +1

    Вот если управляли как в комментарии выше: «мил человек, поправь косяки, иначе придётся попрощаться», не вижу ничего ошибочного. И на интервью кандидат мог хорошо отвечать, а потом халтурить. Есть полно профессиональных собеседующихся. Да и стресс по таким незначительным поводам испытывать ни к чему.

  • Сущности в DDD-стиле с Entity Framework Core
    0
    Это про BizRunner'ы уже. То что выходит за рамки статьи. По поводу этого кода с вами согласен: много boilerplate из ничего.
  • Сущности в DDD-стиле с Entity Framework Core
    0
    DTO вам в любом случае нужен, если мапинг не 1 к 1, не уйдете. А репозиторий и сервис вам зачем, если уже есть метод UpdateBook?

    В примере, кстати Book.UpdatePubDate(date), а не UpdateBook(ChangePubDateDto dto).
  • Сущности в DDD-стиле с Entity Framework Core
    0
    Про ValueType с вами согласен на все 100%.

    Тем более, что EF Core с версии 2.1 позволяет задавать собственные «Value conversions» для таких объектов. Но тут есть некоторые ограничения, главное из которых — если такой ValueObject попадает в expression tree, например — .Where(), то в этом случае из БД загрузяться все обьекты и только потом отфильтруются. Но это можно легко обойти. NHibernate в этом плане гораздо лучше подходит для DDD.

    Не совсем верно. Если например, объявить тип Email, который будет проверять, что строка гарантированно вида #@.#, то в LINQ при сравнении с другой строкой запрос построится корректно, а вот с типом Email EF не сможет. Задача конечно решается через визитор на входе в QueryProvider, но это уже не «из коробки».
  • Сущности в DDD-стиле с Entity Framework Core
    0
    Да, меня тоже напрягает. Да и автора напрягает. Вообще если в read-стеке всегда делать select в dto, то lazy-load не так уж и страшен
  • Сущности в DDD-стиле с Entity Framework Core
    0
    К сожалению подсветка кода Хабра не поддерживает номера строк, а в оригинальной статье они есть. Оставил текст как в оригинале.
  • Иди-ка ты на !@# со своей «токсичностью»
    0

    Вот, кстати, самый нормальный взрослый подход. Только почему-то во многих компаниях до сих пор хихоньки, хахоньки и «да ты — %##%, да что же ты такое написал?!»

  • Зависимые типы — будущее языков программирования
    +2

    А что такое F*?

  • Как генерировать осмысленные коммиты. Применяем стандарт Conventional Commits
    +1
    А если просто <НОМЕР-ЗАДАЧИ-В-ТРЕКЕРЕ> и сквошить все комиты? 1 комит — 1 задача. Кому интересно, пойдет в джиру и посмотрит, не?
  • Дзен и искусство поддержки чистого кода
    0

    Исправлять косяки только в рамках задачи и не трогать остальные запятые и тесты, не относящиеся к задаче

  • Манифест жёсткого программиста
    0

    Например ПО для выставки, которая будет проходить в течение трёх дней ровно через два месяца

  • Манифест жёсткого программиста
    0
    Это если вы можете откатиться на предыдущую версию. А бывают такие системы, которые очень-очень-очень много пишут. Постоянно.
  • Scrum is dead
    0

    Надо взять на вооружение:)

  • Деревья выражений в enterprise-разработке
    0
    А эта штука тоже декомпилирует через GetIlAsByteArray?
  • Деревья выражений в enterprise-разработке
    0

    Спасибо за то что поправили. Я конечно имел в виду C#. В F# ещё и провайдеры типов и проблематика EF в нем не так актуальна.

  • Распараллеливание задач с зависимостями —  пример на .NET
    0

    Присоединяюсь к просьбе сообщить о начале продаж.

  • Директор по здравому смыслу: как перестать все контролировать и начать работать в команде
    0
    Нет, не получается. Тимлид — зам. менедежера по технической.
  • ThinkingHome.Migrator — версионная миграция схемы базы данных на платформе .NET Core
    0

    При условии, что вы пишете seed’в есть такое «костыль»: делаете батник с миграцией init, пишете код, удаляете миграции, вызываете init и migrate. В каждый момент у вас одна миграция. Менее изящно, но на этапе прототипирования бывает удобно. Если pk надо заменить, например.

  • Доступ к данным в многопользовательских приложениях
    +1
    В своей практике я не припомню случаев необходимости в таких пользователях.

    Техподдержка Azure или YouTrack, например, чудесным образом имеет доступ к моим данным в облаке и помогает решать проблемы, когда что-то не работает;)
  • Доступ к данным в многопользовательских приложениях
    0
    Вообще, ограничения доступа которые вы описали в статье, это больше похоже на бизнесовые правила и им место скорее в спецификациях, а не на глобальном уровне. Применяя их на глобальном уровне вы можете столкнутся с ситуацией когда вам нужно получить данные не применяя эти правила.
    Да и тогда нужно будет обращаться к другому контексту, который возвращает не «отфильтрованный» IQueryable. Кроме того этот случай решается «супер-пользователем», который видит все и может логиниться от имени кого угодно. Де-факто такой пользователь почти всегда появляется:)

    На самом деле ничего не мешает использовать спецификации внутри таких фильтров. Я просто не стал усложнять код в примере.
    На мой взгляд, проще ориентироваться в наборе спецификаций имеющих четкое название и четкое назначение чем в куче условий в Where. Тем более что со спецификациями вы уже имели дело.
    Да, но если эти данные вообще не предназначены для данного пользователя зачем ему вообще иметь возможность их видеть? Неявность имеет не только плохую, но и хорошую сторону. В некоторых случаях хорошо, что прикладной разработчик не заботится о доступе. Снижает нагрузку на мозг.

    Кстати говоря, как ваше впечатление от них спустя год?
    Короткий ответ — отлично. Если хотите длинный ответ, то <a href=«www.youtube.com/watch?v=DD3w66Ff8Ms&t=948s.
  • Доступ к данным в многопользовательских приложениях
    –1
    Да, можно решать спецификациями, но это не гарантирует, что разработчик не забудет дописать queryable.Where(spec).
  • Доступ к данным в многопользовательских приложениях
    0
    Использование разных интерфейсов эту проблему решает на 100%: используете DbSet напрямую — фильтров нет. Используете абстракцию — фильтры есть. Если используете глобальные фильтры DbContext.Set<T>() — с фильтрами, DbContext.Set<T>().IgnoreQueryFilters() — без.
  • Доступ к данным в многопользовательских приложениях
    0

    Что вы имеете в виду, когда говорите «оттрекать»?

  • Доступ к данным в многопользовательских приложениях
    0

    Если ну очень хочется, то регистрацию можно вынести в отдельную сборку и подключить к хосту уже ее. Бывает полезно, если хостов много. В общем случае вы правы.

  • Доступ к данным в многопользовательских приложениях
    0
    Предложенный вами подход имеет преимущество: он более явный. С другой стороны вам придется теперь везде писать Context.GetPermittedUsers(). Как проконтролировать, что другой разработчик по ошибке не вызовет Context.Users? В варианте с дополнительным интерфейсом можно вообще не подключать EF к web-проекту и работать только через слой бизнес-логики. Еще на extension'ы не повесить декораторы.
  • JavaScript. Работаем с исключениями и данными в конструкциях async/await без блоков try-catch
    +1

    Обратите внимание на вот такой подход: https://m.habr.com/post/339606/. Все try/catch уйдут, но обработка ошибок останется

  • Чем бизнесу и пользователям грозит борьба РКН и Telegram? Мнения экспертов
    +1

    Например то, что у меня на конкретной машине не было локального кеша и я минут 5 соображал почему у меня Rider пакеты не обновляет

  • О декораторах, сквозной функциональности, CQRS и слоеной архитектуре
    0
    Думаю, доменные события для такого логирования подойдут лучше декораторов.
  • О декораторах, сквозной функциональности, CQRS и слоеной архитектуре
    0

    Добавьте дополнительное логирование в необходимых ветках. Можно явно с помощью императивного кода или с помощью декораторов для декораторов. Это как удобнее. Цель статьи — показать как можно очистить доменную логику от инфраструктурного кода. Взаимодействие инфраструктуры с инфраструктурой — другой вопрос.

  • О декораторах, сквозной функциональности, CQRS и слоеной архитектуре
    0

    Спасибо большое за комментарий. Вы поняли все верно. Я теперь знаю, что донёс идею внятно:)

  • О декораторах, сквозной функциональности, CQRS и слоеной архитектуре
    0
  • Паттерны внедрения зависимостей. Часть 1
    0
    Как гарантировать, что вызов DoSomething из вашего примера произойдет после того как Dependency будет установлен?
  • Паттерны внедрения зависимостей. Часть 1
    0
    «Необязательные зависимости» довольно часто свидетельствуют о нарушении SRP и приводят к NRE. Так что лучше без них.
  • REST API Best Practices
    0

    Или 422, например если валидация не прошла.

  • Почему не работают Уставы и Планы управления проектом?
    0
    Де-факто все это разбивается о нашу судебную систему. Довольно часто дороже судиться, чем расстаться с клиентом. Кроме того, не всегда судебное решение легко исполнить.