Согласен, сегодня общался с ИИ саппортом Яндекс Такси, он мне ничем не помог (иначе как дебильными его предложения не назвать), а заявку закрыл. Думаю, такой подход много экономит Яндексу!
Если брать грубо по фичам, то в бесплатном vscode вполне можно работать, да не очень удобно, но и не блочит никто, и немного привыкнув будет даже довольно быстро.
Кроме того, джетбрейнс сами сокаратили дистанцию натянув убогий скин в духе vscode и попутно еще много чего испортив хорошего.
Сомневаюсь, что автор действительно пробовал настоящий DDD, потому что это просто невозможно реальном мире, кроме некоторых вырожденных случаев, хе-хе.
Действительно, если биться головой в книгу, то может показаться, что теперь все надо компенсировать. Забавно, некоторое время назад смотрел доклад (а по сути рекламу, продажу софта по созданию саг), докладчик реализовывал на сагах покупку билетов, но так и не смог обеспечить полностью корректность бизнес процесса (сам он так не думал конечно), а не смог по простой причине - задача вымышленная. Если вдруг возникает какая-то сложная компенсация, то самое время пойти и выяснить суть происходящего, понять допустимые сценарии, состояния и сделать выводы на уровне кода.
Я бы такие материалы не размещал здесь, есть профильные каналы, сми и тп. для информационно-зависимых. По сути это какой-то слух, сплетня. Обсуждать надо факты, а так - пустой всплеск эмоций, а потом ничего, и спросить не с кого будет за вранье.
Я уже и забыл про него, после опыта с ютрек тимсити и остальными я от спейс ничего не ждал. Джетбрейнс принципиально не делают интеграции со сторонними продуктами, и судя по всему спейс умер именно поэтому - хотели чтобы юзера пользовались только им.
Новый UI не понравился - бестолковый, впрочем, у джетбрейнс с этим нормально было только в идее (видимо разработчики делали как для себя, а теперь эффективные менеджеры рулят), все остальные их продукты сильно так себе по UI/UX. Ну зато теперь бесплатно!
Fleet - это просто легкий фронт к тяжелым бэкендам, он не будет никогда быстрее, чем обычная идея, и никогда в нем не будет плагинов, которые есть для vscode.
Удобство разработки определяется фреймворком в большей степени, а флаттер в разы проще и удобнее того, что есть в нативе и тем более проще чем Котлин мультиплатформ.
Может я не знаю чего-то, но в обычном приложении врядли будет какая-то разница между последовательным исполнением тасков через Channels и этой очередью, async/await не требует дополнительной синхронизации, если не выполнять таски параллельно. Может для работы с какой-то нативной либой это может понадобится.
Пользовался RestSharp, перешел на Flurl, а потом обе эти либы начали ломать свое АПИ, релизить несовместимые версии и так далее. И ладно бы лучше что-то сделали, но нет, еще и багов добавили. И теперь я подумываю использовать голый HttpClient, потому как от этих либ больше вреда, чем пользы.
С Polly тоже самое, взяли и поменяли апи - иди переписывай, а апгрейд гайд очень скромный.
Это просто вахтеры, по поводу и без, и за нормальный принципе ответ меня минусовали, мол ужас, ссылка без копипасты по этой ссылке, хотя там был всего лишь пример.
А dotnet-trace не справился бы с задачей?
Согласен, сегодня общался с ИИ саппортом Яндекс Такси, он мне ничем не помог (иначе как дебильными его предложения не назвать), а заявку закрыл. Думаю, такой подход много экономит Яндексу!
Куда-то пропали все комментаторы, которые расказывали про казахские карты и впн и как все у них хорошо и какие джетбрейнс хорошие )
Ну добавить тут нечего, разве что есть вопросы к открытости, теперь точно можно сказать, что это не последний зашквар.
Если брать грубо по фичам, то в бесплатном vscode вполне можно работать, да не очень удобно, но и не блочит никто, и немного привыкнув будет даже довольно быстро.
Кроме того, джетбрейнс сами сокаратили дистанцию натянув убогий скин в духе vscode и попутно еще много чего испортив хорошего.
А ведь по условиям подписки купленная версия обязана оставаться доступна, пусть и без обновлений.
Сомневаюсь, что автор действительно пробовал настоящий DDD, потому что это просто невозможно реальном мире, кроме некоторых вырожденных случаев, хе-хе.
Действительно, если биться головой в книгу, то может показаться, что теперь все надо компенсировать. Забавно, некоторое время назад смотрел доклад (а по сути рекламу, продажу софта по созданию саг), докладчик реализовывал на сагах покупку билетов, но так и не смог обеспечить полностью корректность бизнес процесса (сам он так не думал конечно), а не смог по простой причине - задача вымышленная. Если вдруг возникает какая-то сложная компенсация, то самое время пойти и выяснить суть происходящего, понять допустимые сценарии, состояния и сделать выводы на уровне кода.
Возникает вопрос, может быть стоит конвертировать данные в более удобный для машины бинарный формат?
Я бы такие материалы не размещал здесь, есть профильные каналы, сми и тп. для информационно-зависимых. По сути это какой-то слух, сплетня. Обсуждать надо факты, а так - пустой всплеск эмоций, а потом ничего, и спросить не с кого будет за вранье.
Я уже и забыл про него, после опыта с ютрек тимсити и остальными я от спейс ничего не ждал. Джетбрейнс принципиально не делают интеграции со сторонними продуктами, и судя по всему спейс умер именно поэтому - хотели чтобы юзера пользовались только им.
Новый UI не понравился - бестолковый, впрочем, у джетбрейнс с этим нормально было только в идее (видимо разработчики делали как для себя, а теперь эффективные менеджеры рулят), все остальные их продукты сильно так себе по UI/UX. Ну зато теперь бесплатно!
Fleet - это просто легкий фронт к тяжелым бэкендам, он не будет никогда быстрее, чем обычная идея, и никогда в нем не будет плагинов, которые есть для vscode.
Удобство разработки определяется фреймворком в большей степени, а флаттер в разы проще и удобнее того, что есть в нативе и тем более проще чем Котлин мультиплатформ.
Какого рода эти уязвимости, реально ли вообще ими воспользоваться ?
Может я не знаю чего-то, но в обычном приложении врядли будет какая-то разница между последовательным исполнением тасков через Channels и этой очередью, async/await не требует дополнительной синхронизации, если не выполнять таски параллельно. Может для работы с какой-то нативной либой это может понадобится.
Тут по-лучше обьяснение - https://github.com/borland/SerialQueue
И что-то мне кажется можно было бы просто использовать Channels.
Пользовался RestSharp, перешел на Flurl, а потом обе эти либы начали ломать свое АПИ, релизить несовместимые версии и так далее. И ладно бы лучше что-то сделали, но нет, еще и багов добавили. И теперь я подумываю использовать голый HttpClient, потому как от этих либ больше вреда, чем пользы.
С Polly тоже самое, взяли и поменяли апи - иди переписывай, а апгрейд гайд очень скромный.
Да, непонятно, ну как, понятно, что хотелось последовательно выполнять таски, но это немного странно, получается такой себе бэкграунд мейн тред.
Это просто вахтеры, по поводу и без, и за нормальный принципе ответ меня минусовали, мол ужас, ссылка без копипасты по этой ссылке, хотя там был всего лишь пример.
Думаю можно зарегистрировать Complex Type и использовать, либо разложить на несколько примитивных коллекций и джойнить через индексы.