Если для одного русского слова есть N вариантов перевода - это не потому что это слово непереводимо. Это потому что другой язык гораздо богаче и передает больше оттенков.
Это как у эвенков есть несколько слов для снега - а у нас просто "снег". Значит ли это что слово снег в русском непереводимо? Нет.
Так же абсолютно, "пошлость" говорит о бедноте языка, а вернее о бедноте общества и сознания тех, кто этим словом пользуется.
На удивление, при применении event sourcing как-то отпадает необходимость в GraphQL.
GraphQL хорош, когда у тебя есть N наборов данных, которые ты не можешь легко менять, и с помощью GraphQL ты можешь заставить сервер вернуть точно такой ответ как тебе нужно.
А в CQRS/ES приложении ты просто меняешь функцию проекции для того, чтобы ридмодель содержала ровно то, что тебе нужно.
Мы в конце концов выпилили GraphQL из системы просто потому что не пользовались им.
Вот тут разбирается реализация этих идей, приводящая к event sourcing.
Грубо говоря, на сервере поток евентов разделяетя по DDD агрегатам, персистятся евенты, а стейт вычисляется.
В реализации вышеупомянутого Resolve, есть View Model — разновидность read model, которая обновляется redux редьюсерами, в том числи и на клиенте (в реальном времени по вебсокету).
Новых больших проектов (которые разрабатываются больше 3-х месяцев) в этом году на WinForms создавалось раза в два больше чем на WPF. Но на WPF тоже создавалось немало. В прошлом году соотношение было примерно такое же, сильного тренда в ту или иную сторону не видно.
Double-clicking the left mouse button actually generates a sequence of four messages: WM_LBUTTONDOWN, WM_LBUTTONUP, WM_LBUTTONDBLCLK, and WM_LBUTTONUP.
То есть из Windows приходят не только "сырые" сообщения о нажатии/отжатии кнопки, но и уже обработанные — двойной клик произошел. И это истинные сообщения (учитывающие, например, скорость двойного клика в настройках мыши).
Так какой смысл игнорировать эти сообщения, и пытаться потом их восстановить задним числом?
Что-то смутно мне подсказывает что все это Windows и так за вас делает — и вам надо просто логировать и более высокоуровневые сообщения (а низкоуровневые прятать/сворачивать).
И вообще в общем случае ввод может прийти и не с традиционных девайсов (с речевого ввода например) и там вообще может не быть keyDown/keyUp...
Командам как правило необходимо делать запросы в процессе работы. И какой толк в этом случае от разделения команд и запросов, если они всё равно получаются сильно связанными?
Если это использовать в связке с DDD — Domain Aggregate, то у агрегата должна быть вся информация для выполнения команды и он не должен делать запросы по ходу этого дела. Единственные запросы у агрегата — сохранение и восстановление своего состояния. При применении eventsourcing там все вообще очень хорошо и красиво абстрагируется.
redux очень похож на CQRS+event sourcing. Данные для чтения — это state, данные для записи — это бекэнд. В серверную архитектуру его, конечно, один в один не перенести, но подходы и проблемы очень похожи.
Подходы похожи, но проблемы заметно другие. Редьюсеры как в redux не написать если все в памяти не хранить, многопользовательский доступ к командам. Плюс проблемы инфраструктуры (евенты тупо могут не в том порядке прийти или вообще не прийти). Но в общем-то все у Грега Янга подробно описано как что решать. С eventsourcing на сервере и redux на клиенте вообще все гладко получается
но разве его подход не аналогичен старому Selenium'у — Selenium RC.
Да, подход похож. Наверное основное преимущество TestCafe для Node разработчиков в том что оно не требует Java, меньше стыков и движущихся частей. А насчет использования WD или Proxy решения — у каждого есть и достоинства и недостатки.
Ну, например, proxy способ не требует присутствия вашего кода рядом с браузером. Если вам кастомер говорит что на какой-то модели телефона что-то не работает, вы можете запустить тесты в этом телефоне просто запустив
testcafe remote --qr-code test.js
и сосканировав qr код. С Selenium надо будет повозиться в таком сценарии.
Теоретически, если Samsung захочет, то завтра доля Tizen устройств будет чуть не ли больше доли Android устройств. Просто поставив Tizen на все Galaxy. Хорошая OS без достаточного количества девайсов не станет платформой.
Кроме того, не надо забывать что Android бесплатен только в урезаном виде без сервисов, а стало быть Samsung делится с Google, чего они не хотят.
Уже показывали телевизор с Tizen. Также Tizen стоит в последних умных часах Samsung. Если свести все вместе, то идея своей OS не так уж и плоха для Samsung. Гораздо понятнее чем, например, Firefox OS.
В файле проекта. А должны быть в базе системы — такие же данные как и все остальные. Доступные через тот же слой доступа к данным.
Это добавило бы гибкости без особенных затрат — глядишь, заказчики сами бы себе формы добавляли…
Делал для внутреннего сайта обработку ответов на нотификацию о комментах. Ну чтобы они сразу и в ответы к комментам превращались. Пришлось повозиться с In-Reply-To, чтобы и в почтовых клиентах треды нормальные получались (ответ на ответ на коммент). Не особенно и сложно — пара сотен строк кода.
Основной геморрой — с выкусыванием истории переписки. Разные клиенты по-разному это оформляют и даже со всеми эвристиками периодически старый мусор попадал в комменты.
Ну и как сказали — Out Of Office нотификации замучали.
Но это было внутреннее приложение. Для внешнего надо конечно фильтры разные добавлять чтобы мусор убирать.
Как уже сказали — Андроид — это бесплатная open source система, а сервисы Google Play — не бесплатные. Не хочешь гуглу деньги платить — делай fork Android-a и заменяй гугловские сервисы своими. Что Яндекс и сделал.
Яндекс это сделал не столько для того, чтобы пользователям было удобнее, а скорее для того, чтобы деньги от этой сборки шли не Google, а Яндексу.
Специально поднял историю по этому отзыву. История касается Report контрола, ребята делали все из кода, причем неправильно (создавали XRControl для каждой строчки данных). Задавали вопросы, им отвечали оперативно и показывали как надо делать. Удаленно подсоединялись к их машине, предлагали даже чтобы мы сами их код отрефакторили. На все было сказано, что у нас дедлайн, просто сделайте чтоб работало.
Ну что еще мы могли поделать? Деньги им вернули.
В свое оправдание можно было бы сказать что мы бы могли сделать такой API чтобы они не смогли бы сделать неправильно. Возможно да, но надо понимать что в данном продукте мы базируемся на системной иерархии контролов, и там особо не изобрести ничего.
Следует ли из этого случая, что с DevExpress не надо иметь дело? Думаю, правильный ответ — смотря кому и смотря для какого проекта.
Я бы советовал тем, кто собирается использовать продукты какого-нибудь вендора компонент, скачать несколько от разных вендоров (в нашем конексте — DevExpress, Telerik, Sencha, Infragistics как минимум) и сравнить что ему больше подходит. Иногда даже по фичам-производительности продукты равны, а подходы разработчиков (стиль API, и все такое) — разные. На вкус и цвет все фломастеры разные. Один мышкой программирует, другой — в терминале. Кроме того, если проект большой, стоит попробовать со службой поддержки поработать — поверьте, там тоже у всех по-разному.
А насчет отзыва — да, и такое бывает. У нас сотни тысяч пользователей — всех счастливыми, увы, не сделать. При этом счастливые реже пишут, чем несчастливые.
Если для одного русского слова есть N вариантов перевода - это не потому что это слово непереводимо. Это потому что другой язык гораздо богаче и передает больше оттенков.
Это как у эвенков есть несколько слов для снега - а у нас просто "снег". Значит ли это что слово снег в русском непереводимо? Нет.
Так же абсолютно, "пошлость" говорит о бедноте языка, а вернее о бедноте общества и сознания тех, кто этим словом пользуется.
Нарисовали бы просто текущий момент.
На удивление, при применении event sourcing как-то отпадает необходимость в GraphQL.
GraphQL хорош, когда у тебя есть N наборов данных, которые ты не можешь легко менять, и с помощью GraphQL ты можешь заставить сервер вернуть точно такой ответ как тебе нужно.
А в CQRS/ES приложении ты просто меняешь функцию проекции для того, чтобы ридмодель содержала ровно то, что тебе нужно.
Мы в конце концов выпилили GraphQL из системы просто потому что не пользовались им.
Вот тут разбирается реализация этих идей, приводящая к event sourcing.
Грубо говоря, на сервере поток евентов разделяетя по DDD агрегатам, персистятся евенты, а стейт вычисляется.
В реализации вышеупомянутого Resolve, есть View Model — разновидность read model, которая обновляется redux редьюсерами, в том числи и на клиенте (в реальном времени по вебсокету).
Вот подобная статья, только с игрушкой: https://medium.com/resolvejs/resolve-redux-backend-ebcfc79bbbea
Новых больших проектов (которые разрабатываются больше 3-х месяцев) в этом году на WinForms создавалось раза в два больше чем на WPF. Но на WPF тоже создавалось немало. В прошлом году соотношение было примерно такое же, сильного тренда в ту или иную сторону не видно.
Ну например, в MSDN написано:
То есть из Windows приходят не только "сырые" сообщения о нажатии/отжатии кнопки, но и уже обработанные — двойной клик произошел. И это истинные сообщения (учитывающие, например, скорость двойного клика в настройках мыши).
Так какой смысл игнорировать эти сообщения, и пытаться потом их восстановить задним числом?
Что-то смутно мне подсказывает что все это Windows и так за вас делает — и вам надо просто логировать и более высокоуровневые сообщения (а низкоуровневые прятать/сворачивать).
И вообще в общем случае ввод может прийти и не с традиционных девайсов (с речевого ввода например) и там вообще может не быть keyDown/keyUp...
Если это использовать в связке с DDD — Domain Aggregate, то у агрегата должна быть вся информация для выполнения команды и он не должен делать запросы по ходу этого дела. Единственные запросы у агрегата — сохранение и восстановление своего состояния. При применении eventsourcing там все вообще очень хорошо и красиво абстрагируется.
Подходы похожи, но проблемы заметно другие. Редьюсеры как в redux не написать если все в памяти не хранить, многопользовательский доступ к командам. Плюс проблемы инфраструктуры (евенты тупо могут не в том порядке прийти или вообще не прийти). Но в общем-то все у Грега Янга подробно описано как что решать. С eventsourcing на сервере и redux на клиенте вообще все гладко получается
Да, подход похож. Наверное основное преимущество TestCafe для Node разработчиков в том что оно не требует Java, меньше стыков и движущихся частей. А насчет использования WD или Proxy решения — у каждого есть и достоинства и недостатки.
Ну, например, proxy способ не требует присутствия вашего кода рядом с браузером. Если вам кастомер говорит что на какой-то модели телефона что-то не работает, вы можете запустить тесты в этом телефоне просто запустив
и сосканировав qr код. С Selenium надо будет повозиться в таком сценарии.
Кроме того, не надо забывать что Android бесплатен только в урезаном виде без сервисов, а стало быть Samsung делится с Google, чего они не хотят.
Уже показывали телевизор с Tizen. Также Tizen стоит в последних умных часах Samsung. Если свести все вместе, то идея своей OS не так уж и плоха для Samsung. Гораздо понятнее чем, например, Firefox OS.
Это добавило бы гибкости без особенных затрат — глядишь, заказчики сами бы себе формы добавляли…
Основной геморрой — с выкусыванием истории переписки. Разные клиенты по-разному это оформляют и даже со всеми эвристиками периодически старый мусор попадал в комменты.
Ну и как сказали — Out Of Office нотификации замучали.
Но это было внутреннее приложение. Для внешнего надо конечно фильтры разные добавлять чтобы мусор убирать.
Яндекс это сделал не столько для того, чтобы пользователям было удобнее, а скорее для того, чтобы деньги от этой сборки шли не Google, а Яндексу.
Ну что еще мы могли поделать? Деньги им вернули.
В свое оправдание можно было бы сказать что мы бы могли сделать такой API чтобы они не смогли бы сделать неправильно. Возможно да, но надо понимать что в данном продукте мы базируемся на системной иерархии контролов, и там особо не изобрести ничего.
Следует ли из этого случая, что с DevExpress не надо иметь дело? Думаю, правильный ответ — смотря кому и смотря для какого проекта.
А насчет отзыва — да, и такое бывает. У нас сотни тысяч пользователей — всех счастливыми, увы, не сделать. При этом счастливые реже пишут, чем несчастливые.