Pull to refresh
10
0
Send message

Мы для задач по работе с веб-сервисами автоматически (не парсинг, а замена/упрощение человеческого труда) используем playwright.dev - разрабатывается Microsoft, поэтому .NET нативный. Работает так же по портам браузера.

Так как мы не боты, а работаем легально, то мы можем связываться с разработчиками сервисов для помощи. Работаем с банками, и вот однажды залетели, что пришлось реально просить помощи и просить добавить нас во все белые списки, чтобы не блокировали. Защита была отечественная. Не реклама, но вдруг кому интересно, то qrator.ru - ребята из Сколково.

Такой же подход я использую и в базах данных

Что вы имеете ввиду, можете поподробнее?

Вообще Станислав Сидристый на каждом своем выступлении на HighLoad/DotNext так или иначе затрагивает работу с памятью. Из последнего, как они микросервисы в один дотнет-процесс объединяли, чтобы память как раз общей была. Плюс есть книга у него на гитхабе по результатам анализа работы CLR/GC по исходникам, правда в полузаброшенном состоянии. В общем, это достаточно известное поведение, если вообще не особенность работы ОС, т.к. по документации происходит вызов VirtualFree.

Рассказали бы лучше, как так у вас в веб-приложении единоразово аж 8 гигабайт памяти выгружается, что за юз кейс такой. Зачем столько объектов, что с ними потом происходит, за сколько это отрабатывается - это же какой-то веб-запрос? Если это отчет, то сколько результирующий файл весит? Гигабайты? Почему бы не использовать IAsyncEnumerable и какой-то пулинг? Или они и так есть? Все это было бы очень интересно узнать, интересная задачка же :)

Они .NET Core 3.1 форкнули полностью, поэтому можно использовать патченный dotnet (заменить крипто сборки по факту) и все будет работать. Мы крутим в докере патченный дотнет + официальный КриптоПро CSP, устраивает. Вот тут можно глянуть их примеры.

Автор молодец, хардово. Но .NET уже давно не про Windows, к счастью, для всех, но, к сожалению, для данной статьи.

Нет никакого медиатора между ядром и инфраструктурой. Нет медиатора внутри ядра. Медиатору отведено единственное четкое место, где он располагается, это интерфейс ядра приложения

Почему именно так? У вас на проекте 1300 команд/квери, столько же хэндлеров, и у них нет общего кода? Этот общий код можно выносить в сервисы из кучи методов и циклических зависимостей, и мы просто всю эту лапшу выносим чуть глубже в ядро. Зачем, если есть медиатор? Максим Аршинов так же упоминал в своем докладе, что будут доменные юз кейсы, но, главное, не делать их командами и квери, а чем-то иным. Мне это кажется отличным подходом. Или вы из-за перфоманса якобы против?

Если честно, никогда не приходилось использововать запросы в бизнес-коде PUT от клиента и сразу в БД. Как можно не удостовериться в валидности запроса, наличии прав, доступном состоянии сущности и т.п. без ее предварительного получения. Поэтому кейс с Edit-ом хороший, но не очень применимый в жизни. По крайней мере, в моей :)

Как известно, запросы на запись значительно медленнее запросов на чтение на уровне баз данных, что отлично заметно по разнице Dapper для Get/Edit в районе 2-х раз. И если у гет запросов можно включить AsNoTracking и получить практически паритет EF - Dapper. То в случае создания новой сущности ее все равно придется отслеживать для получения PK, например. Поэтому было бы очень интересно сравнить POST у EF и Dapper. При условии, что запись медленная в БД, то может трекинг не будет совсем влиять относительно самого запроса :)

P.S.: мне казалось, что я где-то видел или сталкивался, что для каждого Include в EF надо указывать свой AsNoTracking, но могу и ошибаться. Если это так, то совсем неудобно использовать в коде и думать об этом.

P.P.S.: я бы не стал всем рекомендовать налево и направо использование AsNoTracking еще потому, что не всегда разумно вытягивать одним запросом с кучей join-ов информацию. Особенно, когда там есть пересечения в Foreign Keys. У БД есть проблема какого-то там взрыва, когда из-за join-ов приходится много данных одинаковых дублировать, потом эти же дубли передавать по сети и т.п. В EF Core для этого вводили фичу сплита запроса на несколько разных как раз из-за этого. Поэтому ребята на Dapper могут упереться в это и будут руками объединять эти запросы, а так за нас сделает все Change Tracking в EF из коробки :)

Спасибо за статью! Хотел бы добавить, что несколько обработчиков разных запросов можно аналогично с сервисами объединять в один класс, чтобы выносить общую логику в приватные методы, тут нет никаких ограничений и рефакторинг доступен. И сам медиатор используется часто для разделения команд и запросов при использвовании CQRS.

Ну ладно вам, автор же пишет, что с «будущей женой». А с девушками не такой и тяжкий грех. Кто знает, может они договорились снимать квартиру получше, но делить расходы пополам? Не нам судить :)

И статья про код и хобби вообще-то. Идея отличная! Даже вин формс выглядит симпатично :) Не понимаю, почему не перейти полностью в разработку при наличии успехов и выполненных проектов? Планируете ли подключать туда как пользователей друзей/соседей/родственников? Open source? Какие дальше планы вообще? Только для себя или какое-то развитие продукта? В любом случае, автор - молодец и успехов!

Видел скрины решения в вижуал студии .sln. Похоже дотнет, ну по крайней мере один из

Абстракция через интерфейсы понятна. Но чтобы реализацию интерфейса вынести можно было в удаленный сервис, значит эта реализация должна быть полностью независима со своим доменным контекстом и своими сущностями. Эти контексты необходимо как-то синхронизировать. Плюс асинхронные вызовы подразумевают наличие какого-то посредника, через который можно получить ответ. Это получается тот же микросервис, но физически в одном монолитном проекте. Вы об этом?

Просто судя по комментариям и холиварам в сети о микросервисах, основные претензии как раз затрагивают неудобство такой вот работы. И в целом без разницы — в одном это процессе работает или в разных.

Если вы можете привести какие-то более конкретные примеры реализации или источники с примерами, был бы признателен.
А вы можете привести пример, как реализуется асинхронность на архитектурном уровне между библиотеками? Именно об этом хотелось бы узнавать из таких вот статей, а не подпитку для холиваров читать. Получается необходимо, чтобы сервис из библиотеки имел метод для приема задания, куда-то его складывал, а потом куда-то отстукивал с колбеком? Или как это будет по факту с библиотеками? Те же брокеры сообщений или как-то проще можно поступить?
В таблице ниже приведены некоторые результаты:

Хотелось бы ознакомиться, добавьте, пожалуйста!
Но всегда есть некоторые решения, которые можно уже использовать
Скриншот

Да они так-то правильно делают. Судя по тому, сколько у них орущих везде в комментариях людей, потерявших доступ к почте. В таких ситуациях нужен второй фактор. Для одной не очень нужной почты я просто добавил резервный адрес почты и никаких проблем :)
Да ладно, так уж и даже Яндексу недоступны? )
Этот случайный ключ отправляется на хранение в облако Яндекс.Паспорта. А зашифрованный дубликат остается храниться в локальном профиле Браузера.

У вас же имеется доступ в локальный каталог, что греха таить? Я не ругаю и ничего против не имею, но сам факт. Кто захочет не верить, основания найдутся :)
Как ни странно, но только 1% пользователей браузера используют специализированные расширения для хранения паролей

Сколько уязвимостей ежемесячно закрывается в Chromium? Доверие гиков, конечно, не удастся таким образом завоевать. Хотя если их всего 1% или даже того меньше, то и не так страшно.

Чтобы давить на массовость, не хватает дополнительных полей для хранения. Если уж пользователю переходить полностью на ваш менеджер, то иногда требуется хранить еще какие-нибудь сведения (пин-код карты, пин от приложения на телефоне или что-то еще). Еще было бы неплохо показывать качество выбранного пароля, чтобы пользователь понимал, что qwertyhello123 совсем некруто, как говорит, например, KeePass :)

Почему не Argon2 или OSCrypt? На мобильных устройствах отсутствует AES-NI, сейчас же есть модный и быстрый ChaCha20-Poly1305?
Бумажный вид не имеет надежного шифрования, а значит любой неожиданный гость: знакомый, друг, племянник или человек в погонах легко воспользуется вашими записями. Даже если не учитывать, что человек в погонах получит ваши пароли в любом случае, будь они хоть чем зашифрованы.

Безусловно хранилище с менеджером паролей необходимо более достойно защищать — права доступа явно ограничивать, как минимум, для внесения изменений (отдельный пользователь, администратор и etc); использовать фаервол для ограничения выхода в сеть всяких кейлогеров, даже если антивирусная защита их вдруг пропустила.

Согласитесь, такая методика имеет право на существование? А то read-only начитаются хабра и пойдут массово за блокнотами :)
Да нет, там есть прирост, просто необходимо более показательные тесты использовать.

Intel, 4 поколения разницы:

В обычном среднестатистическом режиме работы разница будет заметна, т.к. однопоточные вычисления подросли, ну и многопоточные так же подросли, так что и компиляция будет шустрее. Но нужно еще учитывать, что у Intel совсем неодинаковая ниша у этих процессоров. Хотя там не такой значительный разброс будет.
Позвольте поинтересоваться, а что теперь с Агентом? Сам я начинал в далеких временах именно с него, у вас был отличный клиент под мобилки на j2me и халявные смс-ки. Только потом уже перешел на icq — было модно, как нынче телеграм :) Сейчас волею судьбы приходится опять пользоваться аппаратом из тех времен, и о чудо, ваш агент все еще можно загрузить с официального сайта, и он даже работает! Но даже клиенты на ПК, на iPad и Windows Phone не обновлялись с 2014-15 годов, похоже это увядание? У вас же было объединение агента и icq, а теперь только icq развиваете? Шифрование прикрутили, в веб версии хотя бы https имеется, а у агента в вебе только http. При регистрации почты можно сразу же пользоваться агентом, а icq нельзя :( И в icq очень расстраивает привязка номера телефона, ладно бы просто привязка, дак он еще и палится всем желающим в поиске потом! Это ужасно, выше уже писали в комментариях, даже телеграм пинают за это, да это и неудобно. В агенте вот не так, но как долго будет жить он еще вопрос. В любом случае, не ломайте под j2me, и спасибо, всего вам наилучшего!

Information

Rating
Does not participate
Registered
Activity