• Одних тестов недостаточно, нужна хорошая архитектура
    0
    Стратегии могут быть нетривиальные. Например, время с лагом менее 5 минут считается одинаковым.
    На мой взгляд, явные стратегии в боевом коде читаются и тестируются легче, чем эвристический тест, выставляющий разные значения полей.
  • Одних тестов недостаточно, нужна хорошая архитектура
    0
    1. Потому что с инфраструктурной точки зрения это разные объекты.
    2. Не понял вопрос.
  • Одних тестов недостаточно, нужна хорошая архитектура
    0
    Там более сложная эвристика на самом деле, время учитывается, конечно.
  • Одних тестов недостаточно, нужна хорошая архитектура
    0
    Для победы над ошибками сетевого плана, когда одна и та же транзакция передаётся несколько раз, можно использовать ключ идемпотентности, но он не поможет для решения проблемы незначащих изменений.

    Да, я об этом немного упомянул
  • Одних тестов недостаточно, нужна хорошая архитектура
    0
    Это тоже решение. Если атрибута не повешено, то можно падать при старте приложения, например. Вполне валидное решение. Проблема может быть только в том, что атрибутов может быть много и код будет сложно читать. Я не очень люблю аспекты, но это уже вопрос вкуса.
  • Одних тестов недостаточно, нужна хорошая архитектура
    0
    А какая разница, в какой именно момент будет решаться проблема незначащих изменений? Кажется, что чем раньше — тем лучше, нет?
  • Одних тестов недостаточно, нужна хорошая архитектура
    0
    1. Потому что Equals используется нашим ORM (linq to sql) для определения, одна и та же сущность перед ним или нет. Переопределение Equals кодом, который не соответствует сравнению PK сущностей приведет к тому, что ORM перестанет работать :(
    2. Не каждое свойство одинаково участвует в определении эквивалентности. Некоторые свойства не сравниваются вообще (например, даты). Некоторые свойства сравниваются сложным образом, как линии. В простом случае можно сгенерировать код при старте приложения. Но это делает код сложнее, например для дебага. Код, который написан в статье, можно дебажить, рефлексия используется только для проверки.
  • Одних тестов недостаточно, нужна хорошая архитектура
    0
    1. Неймконвеншн будет не статически проверяться, мне, если честно, не очень нравится
    2. Можно ошибиться в том, что не вызвать такой метод в IsEquivalent
    3. В чём именно проще поддержка? В предложенном варианте со стратегиями именно поддержка проще, потому что нужно просто реализовать интерфейс.
    4. Научить IsEquivalent ругаться можно, но лучше делать это не в рантайме, а при инициализации приложения. Тогда и с производительностью не будет проблем.
  • Одних тестов недостаточно, нужна хорошая архитектура
    0
    Решение в лоб: давайте напишем код, который при поступлении нового изменения заказа будет среди уже существующих изменений того же заказа искать точно такое же

    Вот это разве не то, что вы предлагаете? IsEquivalent — метод класса OrderHistoryItem, то есть сделано, как вы и предлагаете: реализована эквивалентность записей, которые нужно сравнивать. Проблема в поддержке этой эквивалентности.
  • Некоторые мысли о паттерне Visitor
    +1
    Visitor — хороший паттерн, но проблемы начинаются, когда нужно расширять количество обходимых классов в другой сборке, отличной от сборки, в которой определен сам Visitor. Тогда в этих наследниках приходится ожидать один тип Visitor'а и делать cast к наследнику, определенному в этой сборке, что не очень приятно. В такой ситуации уже удобнее бывает просто сделать Dictioary<Type, Action>. С таким подходом потеряем в производительности и возможно в читабельности (хотя и не факт, если такой подход используется часто в кодовой базе), зато получим больше гибкости.
  • Что делать, если в PK Identity закончились значения?
    0
    Есть ещё решение, которое конечно совсем не серебряная пуля, но в некоторых ситуациях вполне реально: удалить суррогатный ключ. О нём не думаешь сразу, но мы, когда столкнулись с переполнением IDENTITY, поняли, что можем вообще выкинуть суррогатный ключ и ничего не потеряем. Так и сделали и довольны :)
    Может конечно возникнуть вопрос, зачем он был изначально :)
  • Опрос айтишников. На «вы» или на «ты»?
    0
    У нас на работе все примерно одного возраста, компания всего 60 человек, все друг друга знают, и общаемся друг с другом мы исключительно на ты :)
    Это — одна из прелестей небольшой компании, конечно)
  • ReactDoc — первое open source решение программы «Единая фронтальная система»
    0
    Спасибо, стало на много лучше.
  • Использование выражений для фильтрации данных из БД
    +2
    Возможно многие просто используют, например, хранимые процедуры для работы из приложения с БД. Не говорю, что это плохо, у всех разные архитектурные принципы. Кому-то важна поддерживаемость кода, кому-то — например скорость. Кто-то просто не решает задачи, где может понадобиться переиспользование кода генерации запросов.

    Что касается темы статьи, то мы используем нашу же разработку Mindbox Expressions, в которой есть метод ExpandExpressions, делающий то же самое, только интерфейс чуть поприятнее :-)

    Так же есть LINQKit, в котором есть AsExpandable, позволяющий примерно то же самое.
  • ReactDoc — первое open source решение программы «Единая фронтальная система»
    +1
    Так и где там пример? Там пара компонентов и всё. Как мне понять, что делает ваш генератор документации, не запуская npm run docs-dev самостоятельно? :)
  • Декабрьский релиз ReSharper Ultimate 2016.3
    0
    Последнее очень раздражает. Такие продукты, как решарпер, просто не в состоянии угнаться за скоростью разработки typescript.
  • Полный список инструментов и утилит для Microsoft SQL Server
    0
    Ой, а только я терпеть не могу все эти визуальные редакторы таблиц и всегда сам пишу скрипты?))
  • Полный список инструментов и утилит для Microsoft SQL Server
    0
    А какой смысл в такой подборке? Предполагается, что читатель прокликает все утилиты, чтобы понять, что каждая из них делает? Их тут 143 и по названию можно понять дай бог в 10%. Почему бы не добавить хотя бы краткое описание для каждой утилиты?
  • Jsqry — библиотека для запросов к JS объектам и массивам
    0
    Да, нужно больше языков, конечно!
    Если серьезно, то по-моему после появления arrow-functions в ES6 или typescript (в котором они были от рождения), это всё на столько бесполезно…
  • Рабочее место .NET разработчика или трудности выбора идеальной конфигурации
    +1
    Да, не представляю, как они там без второго монитора живут. Вот у нас в Mindbox у каждого разработчика по два монитора, а у некоторых — и по три!
  • Как мы перестали бояться тикетов на UI
    0
    Разумеется, вы не можете. Никаких особых флагов, кроме --jsx (кажется, он так называется) не нужны.
    Компонент — generic от его props. Всё, что не указано в generic типе, передавать, разумеется, нельзя.
  • Как мы перестали бояться тикетов на UI
    0
    Мы не рассматривали ExtJs
  • Как мы перестали бояться тикетов на UI
    0
    Как-то так:
    • Сильно уменьшает сложность за счёт именно правильной декомпозиции.
    • Имеет очень низкий порог вхождения: практически любой разработчик может за разумное время поправить баг в UI и не разломает при этом всё.
    • Даёт возможности для статической типизации всего UI. Не думаю, что какой-то другой фреймворк даст возможность проверить, что в "<a hrea" нет опечатки. Какой-нибудь статический анализатор html может это сделать, но это тривиальный случай, статическая типизация даёт на много больше, чем это, но я тут не хочу углубляться. Для нас это очень важно, как можно было понять из статьи.
  • Как мы перестали бояться тикетов на UI
    +1
    Подразумевается, что если технология в продакшне на крупных сайтах — значит вероятность того, что её завтра все забудут, несколько ниже, чем если она менее распространена. По крайней мере я себе этот довод вижу так.
  • Валидация: внутри сущностей или снаружи?
    +1
    1. По моему опыту количество переходов между состояниями много больше, чем количество сущностей. Разумно ли проверять переходы из состояния в состояние?
    2. Валидация в доменной модели подразумевает, что мы валидируем всю модель целиком. Если в результате транзакции оказалось, что модель неконсистентна — значит, мы просто забыли что-то проверить.
  • Как мы перестали бояться тикетов на UI
    +3
    Ой, это только какая-то не та версия. Вот оригинальное видео, а то, что выше — уже какая-то другая версия того же доклада, не та, которую я хотел скинуть
    Вообще у этого чувака много очень смешных выступлений, например вот это про FRP и ClojureScript.
  • Как мы перестали бояться тикетов на UI
    +3
    Да уже несколько лет как :)
    Примерно в тот момент, когда ребята из facebook поняли, что всё это время мы отделяли представление от логики неправильно, и гораздо естественнее создавать компоненты, а не разделять «вёрстку» и «логику» просто потому что так принято.
    У Александра Соловьёва на эту тему просто шикарнейший доклад, обожаю его, можете посмотреть.
  • Валидация: внутри сущностей или снаружи?
    +1
    Понятно.
    В принципе я совсем чуть-чуть рассказал в конце последней статьи (в разделе «Валидация»).
    Но конечно тема очень большая, потому что требований к фреймворку валидации было довольно много. Надо собраться как-нибудь и описать это всё :)
  • Валидация: внутри сущностей или снаружи?
    0
    Ну… У меня, если честно, что-то никаких ассоциаций со стэк-фреймами нет :)
    Пользователь увидит то валидационное сообщение, которое возникло в сущности.
    Тут у нас ещё есть заморочка с тем, что у нас разные приложения работают с одними и теми же сущностями. Например, потребитель может сохраняться через сервисы (значит, на каком-то сайте регистрируется), а может через нашу админку (значит, наш сотрудник создаёт какого-то потребителя зачем-то). И мы должны разные сообщения показывать в таком случае. Так что у нас в коде используются ключи сообщений, а сами тексты хранятся в базе, и различаются для разных приложений.
  • Валидация: внутри сущностей или снаружи?
    0
    Планировал на эту тему следующую статью писать :)
    У нас фреймворк валидации работает следующим образом. Вся валидация находится в сущностях и частично в репозиториях. Ошибки валидации не висят в воздухе, а привязываются к ключам валидации. Для этого у нас есть класс ValidationKey с наследниками, например EntityPropertyValidationKey, который содержит в себе ссылку на сущность и название свойства, к которому он относится. В процессе сохранения данных в базу клиентский код должен связать валидационный ключ с этими данными. Если мы говорим про Web, то данные у нас приходят в полях вью-моделей. При этом данные могут перемещаться от одного объекта к другому. Например, во вью-модели мы создаём не сущность, а какую-то DTO'шку, которая в последствие передаётся в репозиторий. В такой ситуации мы связываем исходные данные с полями DTO'шки, а затем в репозитории связываем поле DTO'шки с полем сущности.
    Говоря «связываем» я подразумеваю, что у нас где-то во фреймворке валидации просто хранится связь валидационных ключей между собой и валидационных ключей и путей по свойствам вью-моделей.
    Надеюсь, хоть что-то понятно, просто не хотелось бы тут ещё код писать :)
  • Валидация: внутри сущностей или снаружи?
    0
    И как это связано с необходимостью переносить валидацию в команды? Нужно просто сделать архитектуру валидации немного сложнее, чем представлено, позволяя отслеживать, как данные перемещаются из одних объектов в другие.
  • Почему я НЕ являюсь фанатом TypeScript
    0
    TypeScript не управляется сообществом

    Поддержка tsx (typescript and xml, аналог facebook'овского jsx для react с типами) была написана сообществом, после упорных доработок была включена в компилятор и уже полгода как доступна в Visual Studio. Официально. Говорить при этом, что TypeScript не управляется сообществом, мне кажется совершенно некорректно.
  • Нагрузочное тестирование – этап обеспечения качества продукта
    +1
    Мне Тинькофф никогда не звонил, кредитов не предлагал, рекламных писем не слал. Так что зря вы нервничаете так :)
  • Как подружить Linq-to-Entities и Regex
    +2
    MSSQL поддерживает загрузку .NET-сборок, функции в которых можно мапить на хранимые процедуры самого SQL. За счёт этого можно сделать поддержку и регулярных выражений в MSSQL, и прокинуть её в тот же linq to sql примерно так же, как это показано в этой статье для EF.
  • Изучение React — для чего, откуда, как?
    0
    Или txs ;)
  • Изучение React — для чего, откуда, как?
    +2
    Не нужно выносить разметку. Она связана с логикой приложения, и это не coupling, это cohesion. Компонент — это логика и представление. Тут SRP не по принципу «ты определяешь представление (как будет выглядеть какой-то элемент)» и «ты определяешь логику (как взаимодействовать с конкретным элементом)», а по принципу «ты инкапсулированный компонент, в тебе представление и логика его отображения».
    Тут правда есть нюанс с тем, как верстальщика с этим работать заставить. У нас процесс построен, что верстальщик концептуально верстает элементы управления, а мы уже из этой вёрстки создаём компоненты, так что у нас нет проблемы.
    На эту тему есть совершенно прекрасный доклад Александра Соловьева Как писать UI без боли. Вообще у него совершенно потрясающие видео на YouTube, очень советую и другие посмотреть :)
  • Flux в картинках
    0
    А я что-то подумал, что это один человек. Ну, бывает :)
  • Flux в картинках
    0
    Да я удивляюсь, что сам dmitriiabramov мне его не посоветовал)
  • Flux в картинках
    0
    Мне тоже очень не нравится эта идея с waitFor. А вы не знаете примеров сравнительно большого open-source приложения с одним сложным (желательно immutable и полиморфным) стором? :)
  • 40 ключевых концепций информационных технологий доступно и понятно
    0
    А мне наоборот очень понравилась аналогия с рекурсией. Я не вижу тут цикла. Есть функция, которая принимает человека в зале, возвращает номер его ряда. Она определена через себя саму же и через константу 1 для тех, кто сидит в первом ряду. По-моему, это классическая рекурсия, и, на мой взгляд, одна из лучших аналогий в статье.
    Мне кажется, не нужно хотеть от аналогии многого — на то она и аналогия, чтобы не соответствовать на 100% :)