— https://dotnet.microsoft.com/learn
— https://ru.stackoverflow.com/a/416585/422180
— https://metanit.com
— https://professorweb.ru
2. С# для веб
— https://docs.microsoft.com/ru-ru/aspnet/core
3. C# для десктопа
— https://docs.microsoft.com/ru-ru/dotnet/desktop
4. С# для игр
— https://ru.stackoverflow.com/a/609901/422180
5. С# для мобильной разработки
— https://docs.microsoft.com/ru-ru/dotnet/maui
6. Годные ютуб-каналы
— https://www.youtube.com/c/CODEBLOG
— https://www.youtube.com/c/AndreyShyrokoriadov
— https://www.youtube.com/c/DevJungles
— https://www.youtube.com/user/Shmachilin
Шапка: https://pastebin.com/HT7Hi6FD
Прошлый тред: >>2601326 (OP)
Смысл этого тредиса? Никто не использует дотнет. Все новые цифровые проекты пишутся на джавовском спринг буте или голанге. К заводчанам, пишущим системы автоматизации под виндовсы, вопросов нет
Мы пишем системы автоматизации под виндовсы на заводе. Свободен, листай ленту дальше.
Перекотился!
>>2621961
Давайте лучше обсудим .NET 8 Preview 1
Ну. Попробовал. Наколеночное решение за 5минут. Думаю если именно задача стоит такая - можно сделать нормально для твоих целей.
Спасибо, наконец-то кто-то нашёл решение, и тему можно закрывать.
Да. Немного пролюбился. Во-первых, event надо было к хендлеру добавить, а то я смотрю, в редакторе чет нет события. Ну и по хорошему - чуть сложнее обработку всего этого дела, типа не просто тупа менять селект при клике по ноде, а проверять, на плюсик клацнули или на саму ноду, вот это вот все, по хорошему - там еще допилить шифты всякие, более сложное поведение.
Но я просто про то, что вроде как сказали "Попробуй", будто это какая-то невыполнимая магия или даже если выполнимая, то придется ебаться со всякими winapi и прочим добром. Типа сделать, если задача такая - думаю можно часа за 4 со всем-всем че надо.
По формуле NE_LOH.
Ну и пытаться анализировать перечеркнутый ценник, это конечно сильно.
Маппинг диапазона пробовал? Хз как это называется по научному, но во всех графических программах популярна функция приведения одного диапазона к другому и называется что-то вроде Map by Range.
Не, простой маппинг возвратит 2769.
Купи еще один предмет. Нам нужна статистика.
Куда делся этот чел https://github.com/zeul72
У него были видосики на ютубе и они были прям оффигенные. Типа мне - сильно помогли те что по сокетам были. Хотел посмотреть че у него нового, но даже старое найти не могу.
Может быть вы в курсе.
Просто это был единственный чел по сокетам, кто относительно нормальный пример привел, подача тоже вроде была норм. Да и код у него прикольный.
Много способов, можно в реестре поискать, можно сделать запрос к WMI по MSFT_VSInstance, можно запустить C:\Program Files (x86)\Microsoft Visual Studio\Installer\vswhere.exe, можно тупо обойти все диски в поисках папки с Visual Studio в Program Files.
благодаря твоему вопросу, я узнал из гугла много нового
Дык перебором это понятно. Я думал есть для этого какая-то специальная штука, которая выводит связи, мб по лицензии. Вижуал студия — это лишь условный пример. Потому что бывает такой бардак, что программа например повышается по примеру 1, 2, 3, а потом вдруг начинает привязывать версию к году 2010, 2011, а потом и вовсе дает имена вроде Windows Vista.
>Реестр
Непредсказуем. У меня две версии приложения, и только одна прописана в реестре.
>MSFT_VSInstance
Это специально для вижлы
>vswhere.exe
Это тоже.
Остается тупо перебор жестких дисков. Но это же пиздец, оно может быть установлено где угодно и не факт что в Program Files. При этом некоторые плагины определяют вмиг все релизы приложения.
>Реестр
>Непредсказуем. У меня две версии приложения, и только одна прописана в реестре.
Епт, забыл что у приложения сменился владелец и теперь лежит в другом месте. Есть оба в реестре. Наверно этот вариант будет самый нормальный.
Не может существовать такой штуки. Пользователь, к примеру, мог тупо распаковать архив с нужной ему программой в удобном месте, и как волшебная штука должна её найти, кроме полного обхода всех дисков?
Для каждой программы надо писать свой локатор и юзать аналогичные вижуалстудии способы, или хотя бы предположить, что большинство пользователей не меняет дефолтный путь установки в Program Files, показывать список оттуда, а если ничего нет, предлагать пользователю самому указать путь.
> Купи еще один предмет. Нам нужна статистика.
Купил ещё предмет за 1200.
Вообще, я смог получить 2500 и 1300. Но это какая-то бессмыслица. А если я куплю ещё предмет за 2к, тогда стоимость в минус уйдёт что ли блять.
Яж пошутил, кек.
Этож классика.
В любой непонятной ситуации делим меньшее число на большее и получаем множитель.
3000 \ 6500 = 0,46
2500 \ 6000 = 0,41
Так пропорции например определют. Далее нам интересно а какое соотношение купленной тобой хуйнюшки к изначальнйо цене
500 \ 6500 = 0,07
И какую связь мы видимс?
0,46 - 0,41 = ~0,07
В сообщении присутсвует слово из спам листа
Ты или наркоман, или гений. Пока не пойму твои письмена. Походу придётся завтра купить ещё один предмет, за 2к в этот раз.
>>2622114
Есть еще типа ... видел же алгоритм. Типа ты диапазон можешь регулировать при помощи кривой. Такой херней обычно пользуются при сглаживании ключей анимации.
У тебя в начале может быть более высокое падение, а под конец понижаться все меньше. Ты это так просто не поймаешь, эта кривая может быть действительно сложной, аля безье-сегмент.
Ща найду.
Нашел! Lerp называется. Все вылетело из головы.
https://youtu.be/YJB1QnEmlTs
>тогда стоимость в минус уйдёт что ли блять.
Ну так ты покупаешь по дефолной стоимости, поэтому в этом случае ты да, технически уйдешь в минус.
Вангую счетчик достигнет нуля и для тебя "выгодное предложение" закончится, либо чем ближе к нулю, тем меньше скорость падения цены, как на видеорил >>2622136
Откуда пошла рекомендация делать мок зависимости, код которой ты не контролируешь? В чем ценность таких тестов? Это словно пальцем в небо, где ты гадаешь как бы ответила система, хотя на самом деле не знаешь. Я еще понимаю мок какой-нибудь библиотеки или простенькой хуитки, которая дает API и у нее мокают клиент. Но несколько раз видел, когда мокали клиент для огромной ебы, где дернув ручку создается целая гирлянда всевозможных объектов и состояние системы меняется, что простыми моками это либо не описать, либо займет весь день на один тест.
Прикольно ты спросил в тредах про джаву и шарп одновременно.
Тесты бывают модульными и интеграционными. В модульных ты проверяешь работоспособность одного конкретного модуля, который должен корректно работать, если все используемые в нём модули также корректно работают, и их работоспособность ты проверяешь модульными тестами уже для них. Ну и в интеграционных проверяешь, как модули работают вместе. Что может быть проще?
Модульный на то и модульный, что зависимости обычно представляют твой собственный код, который ты знаешь как работает и можешь закрыть качественными моками, чтобы тестировать в изоляции один класс, например. В случае интеграционных ты сталкиваешься с ситуацией, когда ты интегрируешься с какой-нибудь сторонней хуетой к которой у тебя есть библиотека для доступа к API, но мокать ее ответы не имеет смысла, т.к. ценность таких тестов околонулевая и ты не сможешь предугадать правильные ответы во всех случаях
Что значит не можешь преугадать? Ты тестируешь генератор случайных чисел что ли? Или всё-таки задокументированную функциональность с чётким и однозначным поведением? Вот эта "сторонняя хуета" звучит так, будто она невесть откуда взялась в проекте и никто не знает, что это и зачем. Хотя в реальности никогда так не бывает, по крайней мере, не так часто, чтобы категорично заявлять о полной бесполезности любых моков.
Просто читай Фаулера - он все расписал про моки. Моки в тестах - горе на проекте
>Просто читай Фаулера
Как же я проиграл. Этот старый теоретик на полном серьезе пишет юнит-тест на рест-контроллер где он мокает репозиторий блядь, и тестирует ручку, лол.
https://metanit.com/sharp/wpf/14.php
Короче, я выяснил. Нет там никакой формулы нахуй. Они тупа отнимают стоимость купленных предметов из общей стоимости. При этом они считают минимальную стоимость bundle так: берут предмет с наименьшей редкостью и на основе этого задают стоимость. Мин. стоимость получается от 100 до 500. Редкость это просто формальность, типа: Легендарный Автомат или Эпический Автомат.
Вот допустим я хочу сделать словарь, в котором ключом будет массив интов. Но они должны сравниваться по значению всех элементов (их будет мало в моём случае).
Есть ли что-то штатное или самому пилить?
>Смысл этого тредиса? Никто не использует дотнет
это тред для обсуждения перекатов. ну и немного в него спамят под дотнету - но это прохожие что не в теме сути треда.
Это надо перебирать все итемы?
На гитхабе звёздочек примерно как у MAUI и больше, чем у WPF. Можно смело юзать в проде.
Правильно понимаю, что нужно что-то типо этого сделать?
https://ru.stackoverflow.com/questions/777089/c-%D1%81%D0%B5%D1%80%D0%B2%D0%B5%D1%80-%D0%B7%D0%B0%D0%BF%D1%80%D0%BE%D1%81%D1%8B-%D0%BF%D0%BE%D1%82%D0%BE%D0%BA%D0%B8-%D0%BA%D0%B0%D0%BA-%D1%81%D0%BE%D0%B7%D0%B4%D0%B0%D0%B5%D1%82%D1%81%D1%8F-%D0%BE%D1%87%D0%B5%D1%80%D0%B5%D0%B4%D1%8C-%D0%B7%D0%B0%D0%BF%D1%80%D0%BE%D1%81%D0%BE%D0%B2
ты же понимаешь что никто ничего не понял из твоего пояснения?
какой то поток слов понятный только автору.
потому что слизан с жавы, которая мегаговно
если бы создавался как котлин, то было бы шикарно
Вот только Котлин безыдейное мертворожденное дерьмо, слизанное с сишарпа года 2012, так что насчет шикарно это орево
такое ощущение что его специально придумали чтобы тренироваться костыли приделывать
>>2623142
C#, как и Java, и Kotlin - это мертворожденные и увядающие языки, мечущиеся между двух ниш.
В будущем останется только 2 стула:
1. Razt для системщины и байтокрутов.
2. Pitun для высокоуровневых макакингеров.
Остальные промежуточные двурушники умрут.
Поддерживаю.
Единственная адекватная проверенная временем технология для GUI, дружественная к программисту, с низким порогом входа и с лучшим перформансом на рынке, с самым коротким путём от открытия IDE после обеда до MVP к концу рабочего дня.
Жива и здравствует до сих пор, потому что ничего лучше так и не смогли придумать.
> увядающие языки
> C# и .NET каждый год обновляются
Я даже уже заебался следить за новыми фичами. Каждый год блять что-то новое.
Ну это как барахтающийся утопающий. Брызг, пузырей, шуму, визгу много. А толку - мало. Плавать надо уметь в новой реальности. А не суетно пускать автоматные очереди бездумных изменений, чтобы хоть как-то удержаться на плаву.
Это верный признак конца.
> Плавать надо уметь в новой реальности
Угадай на каком языке написана большая часть современных мобильных игр.
Ты просто не пробовал
В котлине код лаконичнее и выразительнее
И многие фичи там есть что в шарпе и не будет никогда
Только вот в юнити свой рантайм, свой сишарп, отстающий от основной версии. И вообще он зачастую транспилируется в код на крестах, а уже потом компилируется нормальный крестовый код.
На юнити свои особые практики разработки близкие к крестовым, с минимизацией аллокаций. С преаллокацией больших объектов. Это просто крестодрочево на шарпе. И в общем-то то, как это уродливо выглядит, как бы намекаем нам на то, что сишарп в юнити - это просто как пропихнутый по блату неликвид, который по хорошему надо менять на кресты или раст.
Юнити - это самый убедительный аргумент в пользу того, что сишарп не пригоден для разработки игр, и используется там в силу внешних причин (микрософт просто его туда пропихивает не взирая на объективные потребности рынка).
Выдумал какое-то соломенное чучело и сам же разъебал его. Типичный шизоид.
IA
IB :IA
MyBaseClass :IA
MyChildrenClass :MyBaseClass :IB
Задача в том, что я железно должен соблюсти два правила:
1. MyBaseClass обязательно должен реализовать интерфейс IA
2. При обращении к IB должен видеть функционал IA
Проблема в том, что выглядит так, что интерфейс IA используется как бы дважды.
Нельзя, в ASP.NET встроена проверка, что если ты пишешь проект в соло, он детектит все твои счета в банках и электронных кошельках и запрещает по ним входящие платежи.
Он же не сказал какой геймдев. Может он клиент для казино на юнити собрался писать.
> в геймдеве хоть деньги есть
Есть, да не про вашу честь! Войти на тот же рынок мобилок тяжело, нужен креативный подход. А если ты решил на дядю работать, то там платят копейки.
>Пытался сделать словарь, где ключ-id чата - идея говно, не работает.
Ты что-то наебланил, такого не может быть.
>Может он клиент для казино на юнити собрался писать.
Угу. Считать, что можно заработать бабки разрабатывая для мобильного казино, примерно то же самое, что считать, что можно разбогатеть будучи обычным крупье в стандартном казино.
>"Врёти нинужна"
Не считаю так.
Бтв, недавно начал дрочить задачи с codewars, + курс ulearn'a.
>- иди нахуй с треда куда-нибудь в питонотред
пришел от туда)
для чего нужны литкод и алгосы для очередного шарп крудошлепа?
винда умирает, перекатывайся в разработку gtk приложений на Си или Расте
Есть AuthenticationService, который занимается входом/выходом. В нём есть класс Account, который хранит данные о текущем пользователе.
Мне нужен ещё один сервис (пик 2), который будет хранить данные игрока в свойстве Player (по аналогии с Account). Внутри будут данные: UserId, Coins, Tokens, Nickname и тп. Вопрос: как можно назвать сервис, который на пик 2? GameService уже есть. Можно назвать PlayerService, но как-то мне не нравится такое обращение "playerService.Player". Хотя так логичнее всего наверное... Может UserService, хм.
Че этот интерфейс делает, так и называй.
С точки зрения архитектуры - у тебя тут перемешаны интерфейсы. Потому - это должен быть не сервис а фасад какой-нибудь смешанный со слушателями.
Но в твоем случае - очевидно, что у тебя сущности доступа к игроку - смешаны с сущностями которые за рекламу отвечают. Отвязывай их. Делай как человек - IAdService, ITokensService, Inventory, Profile...
А вообще, можешь сделать как делают деды в непонятной ситуации. Вот смотришь внимательно на то где это применяется, и добавляешь слово Context. Допустим у тебя эта хуйня, как видно из методов - применяется в какой-то хуйне связанной с магазином. Так и делай: ShopContext. Player переименовываешь в Consumer. Выглядеть будет так: context.SetNikname("PodzalupniyTvorojok"), context.Consumer.Coins.
А нахера тогда спрашиваешь? Все равно придется учить, все равно придется ходить на собесы.
Задачи пикрил. Я забиндил цвет к прямоугольнику и в текстбокс правее забиндил через IValueConverter этот же цвет в HEX-представлении. Связка двухсторонняя.
Проблема в том, что пользователь может ввести неверный формат данных и это надо как-то регулировать: либо отменить конвертацию, либо вернуть текущее валидное значение.
А, все, надо вернуть null. Даже текстбокс автоматом подсвечивается красной рамкой — удобно.
Нужно возвращать DependencyProperty.UnsetValue, иначе в тексбокс в обратку придет пустой цвет.
Это надо делать копию данных, над ней издеваться, а уже потом переносить данные в оригинал. Но это же лютый пиздец, это же надо вручную перебирать каждое свойство.
>>2625804
>>2625811
Хватит хуйней страдать. Чел 5 лет плюсы изучал и тайпскрипт и не занет сколько нужно на изучение шарпа.
Лучше ответье на вопрос >>2625795
Ну ля, а к собесу как готовиться? Гц этот ваши, лохи и прочее.
Хм. Т.е. сделать опции не как синглтон?
Новый экземпляр сервиса опций заново читает файлы, а после редактирования их сохраняет. Затем можно перезагрузить опции в другом экземпляре если надо в рантайме или при следующей перезагрузке.
С точки зрения производительности хуже, но без ебли глубинного копирования. Найс, мне нравится.
Я ничего не забыл?
ну так то синглтон синглтону рознь. синглотн ака Service.Instance зло, а через DI нет
однако и даже первый вариант не всегда зло. например то же логирование.
да и биндинг настроек вью тоже идет на сигнлтон и ничего. Ну конечно если ты не хочешь делать автотесты гуи на уровне контролов и подменять при этом настройки - а ты этого не захочешь точно.
Я давно делал свою либу для своих нужд для работы с TCP.
Ну так вот. Я чет в последнее время хочу к ней вернуться.
И че меня смущает в ее дизайне.
А вот че.
Есть интерфейс: IProtocol
Собственно вот такого вида:
interface IProtocol<TMessage, TContext>
{
Task<TMessage> ReceiveAsync(PipeReader reader, TContext context);
Task SendAsync(PipeWriter writer, TMessage message, TContext context);
}
Меня тут бесит как раз этот самый TContext
Он нужен, потому что для части протоколов - получение сообщения зависит от всяких шифрований-хуиваний и прочих специфичных хуень.
Но он жутко бесит, в случае, если этого не надо, или я просто хочу продемонстрировать работу на примере Echo-сервера.
Вот че делать?
Мне не хочется делать IProtocol который это будет обжектами заменять. А делать интерфейсы и реализации классов под случай, когда с контекстом и без - тоже не хочется.
Можно конечно сделать в духе:
IProtocol<TMessage> : IProtocol<TMessage, EmptyContext>
Но типа тоже как говно выглядит, тем более, что тот кто будет реализовывать интерфейс - будет этот EmptyContext видеть.
А как решать - я хуй знает.
А зачем тебе ValueTask?
Если операции асинхронные - всегда Таск.
Если чаще нет, чем да, ну блескни смекалОчкой в ПРе и юзни ValueTask, если там кешхит хороший
Как я понял Context некая частная штука. Поэтому я бы его вообще не отображал в интерфейсах. Пускай его используют конкретные классы.
В Djinni масса народу лезет на все сеньерские вакансии где нужно 5+ лет опыта и на многих вакансиях делает т50-70+ откликов, а отклик не поставить там джуну если у него стоит 0-1 год опыта.
Это щас джуны настолько наглые что ставят 5 лет опыта в системе и подаются хоть на архитекта или реально рынок спецов настолько переполнен? Такая же ситуация с мидлами.
Война же не затронула настолько сильно рынок опытных специалистов, или я ошибаюсь?
Такое чуство что вакансия не сеньерская а джуниорская без опыта, и так на многих сеньерский-мидловых вакансиях
Контекст, в данном случае - это такая хреновина, которая отвечает за специфику протокола.
Допустим, вот у нас есть протокол, который по дефолту - после обработки запроса - закрывает соединение. Но если передан флаг KeepAlive - сервер не должен закрывать соединение после. Либо, у протокола есть возможность разные типы шифрования использовать, в таком случае - в контексте содержится информация о том, как шифровать сообщение. Ну и прочая фигня, которая нужна парсеру в зависимости от котнекста соединения.
Ну, а я - еще и хочу же экономить, не создавать кучу парсеров, в которых отличается только контекст, потому хотел, чтобы IProtocol- был один на тип соединения, типа: Для хттп - HttpProtocol : IProtocol<HttpMessage, HttpContext>, для модбаса - другой: ModbusProtocol : IProtocol<ModbusMessage, ModbusContext> ну и т.д.
А идея вообще в том, чтобы в контексте оно прятолось и было типа так:
while(httpContext.Request is null){
var httpMessage = await httpContext.ReciveAsync();
httpContext.Request = new HttpRequest(httpMessage);
await application(httpContext);
if(context.Responce is not null) await httpContext.SendResponce();
if(httpContext.KeepAlive) httpContext.Reset();
}
Просто уродливо когда со стороны какой-то EchoServer показать хочется.
Слишком часто происходит следующего вида хрень:
Просто подчеркивается рандомный кусок текста красным и проект просто не хочет собираться. Просто с нихуя.
Помогает просто перезапуск студии.
Но бесит жутко.
ХЗ как чинить нормально.
Раньше такое случалось только совсем уж в здроровых проектах. Но сейчас - проектик на 20к строк - уже начинается.
Это вонючие вкатуны, крутящие опыт, забей. Во фронте с этим вообще пиздец.
Снеси нахуй статику. И использую объекты. У тебя один и тот же чекбокс, который живёт у всех пользователей
Снеси нахуй статику. И использую объекты. У тебя один и тот же чекбокс, который живёт у всех пользователей
Отклики на вакансии никогда не соответствовали реальному положению дел. Есть боты всяких агентств, автоматически рассылающие отклики. Есть отчаявшиеся вкатуны без опыта, на авось откликающиеся на всё подряд. Есть шизики, услышавшие у инфоцыган, что требуемый опыт можно игнорировать. Есть те, кто жопой читает описание вакансий. Есть наёбщики, посмотревшие видосики "как убедительно пиздеть о своём опыте". Ну и от силы 1-2 сеньора, подходящих под описание, которые откликнулись заодно на 50 других вакансий.
>Ну и от силы 1-2 сеньора, подходящих под описание, которые откликнулись заодно на 50 других вакансий.
Стоит еще учитывать, что по факту нормальные вакансии изначально заполняются через агенства, аутсорс/аутстафф или свои каналы. Т.к. все сеньерные сеньеры уже давно во всех базах и их обзванивают в первую очередь. Плюс пылесосят все нормальные резюме в общем доступе. И когда уже никого не нашлось вакансия выкидывается в эфир, в надежде, что среди набежавжих окажутся те самые пара человек которые чудом проскочили мимо пылесоса.
1. Прочекай все расширения. Очень часто такая проблема бывает из-за кривого расширения или конфликтов между ними.
2. Попробуй обнови студию. В 2022-й в одном из билдов была такая проблема, когда студия на больших проектах теряла все референсы и даже перезагрузка не всегда спасала.
Я после того как до последней текущей редакции обновился и поотключал большинство расширений - проблема исчезла.
>Есть наёбщики, посмотревшие видосики "как убедительно пиздеть о своём опыте".
Разве все настолько плохо если врать о опыте? читал много отзывов о вкате через убедительный пиздёжь о своем опыте, у многих всё получалось без проблем, получали джуна-мидла без опыта, да и человеку который пиздит, ему же хуже от этого не будет, раскроют ложь в одной конторе пойдет на 200-100гу в другую.
>раскроют ложь в одной конторе пойдет на 200-100гу в другую.
"И что это за профессия такая, прости господи! Сын лейтенанта Шмидта! Ну, год ещё, ну, два. А дальше что? Дальше ваши рыжие кудри примелькаются, и вас просто начнут бить."
У меня из расширений - только CodeMaid и тема от которой глаза не вытекают.
Попробую завтра обновить.
Просто реально. Типа раньше - подобное было, но на больших проектах, можно было понять. Но тута началось - даже на небольшом. Всего 4 проекта в солюшне, 20к строчек в сумме. Оно уже ломается. Обидно до дури.
Потому что первое не Class1 не имеет никакого отношения к T.
Компилятор не может вывести зависимость типов, да никто не может, ведь они не связаны
Сделаешь ты потом new Generic<string> и как по твоему Class1 должен неявно кастоваться к string.
>Сделаешь ты потом new Generic<string> и как по твоему Class1 должен неявно кастоваться к string.
То есть эээ... два инстанса Generic<T> с разными типами должны неявно приводиться один к другому?
Я не программист, шарп просто хобби, но знаний по женерикам достаточно, чтобы самому понять, почему эта хуйня инвалид, но вот заклинило и всё.
"Интересно" мозги неработают.
Задача - пикрил. Есть один источник данных в виде цвета aRGB.
А есть два UI-окна, которые биндят этот цвет. Одно окно должно отображать канал Alpha(Opacity), а другое собственно цвет RGB.
С получением данных проблем нет — я это сделал через IValueConverter и сепарировал каналы.
Но представим, что пользователь в окно Opacity вводит новое значение. Конвертору, нужно знать два значения Opacity и RGB, чтобы собрать в кучу и высрать полноценный Color. А конвертер так не умеет, он знать не знает про RGB и где его взять.
Я пытался биндить цвет к parameter в ValueConverter, но он не является DependencyObject. На SO советовали юзать IMultiValueConverter, но это же совсем другая херь — она подразумевает, что у меня 2 источника и одно свойство. А у меня наоборот один источник и два свойства.
Есть идеи?
Что чел имел ввиду? Что это за зверушка такая без Binding, без StaticResouce, без указания неймспейса через двоеточие?
как сделать чтение из одного файла в нескольких одновременных процессах??
Так в файл записывается белиберда, не соответствующая действительности.
тебе для чего вьюмодели дадены? чтобы хранить в них данные для вью. вох и храни
>>2628597
а оно работает? видеть бы его в работе
>>2628634
и никто не понимает что ты вообще делаешь. На пике прочитал ты файл, а потом параллельно начинаешь пихать его Bag которая в принципе не предназначена для "должен быть порядок"
>тебе для чего вьюмодели дадены? чтобы хранить в них данные для вью. вох и храни
А у меня что? У меня свойство типа Color и хранится во вьюмодели. Два текстбокса биндятся к этому свойству, только одному нужен альфа канал, а другому каналы RGB. И каждый тексбокс должен править ТОЛЬКО конкретный альфаканал, а не цвет целиком.
А я напоминаю, что тип Color - структура и ее суб свойства не являются INPC или DP.
Пытаюсь к ValueConverter приклеить DependencyProperty. Чет нихера не выходит. Ща подготовлю демо-проект.
Вкратце, если наследуюсь от DependencyObject, то возникает ошибка в рантайме, мол источник биндинга is null (а это 100% не так). Если наследуюсь от FrameworkElement, то ошибки нет, но и свойство не обновляется. Если я юзаю не Binding, а StaticResource то обновление свойства регистрируется.
Чет с визуальным деревом и данные теряются.
Вроде тут поясняют, но я пока не разбирал.
https://www.codeproject.com/Articles/18678/Attaching-a-Virtual-Branch-to-the-Logical-Tree-in
>а оно работает? видеть бы его в работе
Ну вот у меня ошибка. Я не понимаю что имеется ввиду.
а я напоминаю что вьюмодели для этого и нужны - давать данные для вида. И если вдруг части Color не являются INPC и это нужно, то делается ColorViewModel где этот Color будет иметь INPC свойства своих частей.
Это я не говорю о том, что конвертер это "че хочу то пишу" и туда можно запихнуть и вьюмодель попутно к данным, чтобы он на нее опирался
Проблема проброса DataContext в хамл, что не состоит в дереве - ну это другая проблема
>Я не понимаю что имеется ввиду
ну скорее всего он потерял неймспейс ибо писал в блокнотах пример и вставил.
>то делается ColorViewModel где этот Color будет иметь INPC свойства своих частей.
Я этого хочу избежать (хотел), я не хочу делать отдельный класс. У меня все завязано на Color.
Я думал это дерьмо легко поправить через конвертеры или мультибиндинги, но тут целое ракетостроение получается.
> и туда можно запихнуть и вьюмодель попутно к данным, чтобы он на нее опирался
Не запихнешь. Как я конвертеру передам вьюмодель? Если бы я мог, я бы передал Color.
>ну скорее всего он потерял неймспейс
С неймспейсом тоже ошибка.
> Не запихнешь. Как я конвертеру передам вьюмодель? Если бы я мог, я бы передал Color.
Наследуешь конвертер от markupextension и передаешь что душа пожелает.
ну чудес не бывает. Если тебе нужно INPC и что то не обладает INPC то ты делаешь INPC или делаешь вообще другой подход
> Как я конвертеру передам вьюмодель?
просто.
конвертер это просто класс реализующий интерфейс. По этому интерфейсу в него попадет значение из биндинга. но когда ты создаешь конвертер в ресурсах контрола - ты же его инстанцируешь. и можешь установить его свойства как и в любых других контролах.
или то же самое но в markupextension - тут просто инстанс конвертера создается "на месте"
>С неймспейсом тоже ошибка.
ошибку в студию тогда.
>markupextension
Почему он, а не DependencyObject или FrameworkElement? Ведь туда тоже можно запихнуть что угодно и передать что угодно.
А как юзать markupextension? Ща будет ор, что свойство не является Binding. Вот этот пример и идет по этому пути >>2628597
Ссылка на референс: https://pastebin.com/VxF1c5ma
Там свойство объявлено как Binding, но я не понимаю как это запустить.
>ошибку в студию тогда.
пикрил
в хамл ты можешь создать любой объект и задать его свойства - как ты делаешь с контролами
markupextension позволяет создавать объект внутри { } и тоже задавать его свойства
а сам этот BindingWithBindableConverterParameter показывает пример "так можно", не более типа "смотрите можно сделать свой биндинг", хотя это просто обертка над обычным биндингом и кроме примера ни на что не годится.
Шутишь? У меня год опыта коммерческой разработки, и я по твоему должен конкурировать с вкатунами?
Ну смотри, вот проект: https://transfiles.ru/l90fh
Пикрил 1. По идее, если понижать значение текстбокса Opacity, то оранжевое окно должно становиться прозрачным, но сохранять свой оранжевый цвет.
Конвертацией заведует OpacityConverter, в нем есть обычное депенденси свойство, которое биндится к оранжевому цвету, но цвет остается черным.
Поэтому любое изменение окна Opacity моментально искажает цвет (пикрил 2).
Вот что не так? Почему биндинг не срабатывает?
>markupextension позволяет создавать объект внутри { } и тоже задавать его свойства
Но нельзя биндить эти свойства. А чтобы это реализовать, свойство должно быть Dependency, а чтобы его реализовать, я должен наследовать DependencyObject или Framework Element, но множественное наследование запрещено.
Поэтому MarkupExtension для меня бесполезен. А DependencyObject или Framework Element не работают.
В общем печально, что нет решения для казалось бы очевидной задачи. Ну нельзя даже Color расщеплять на INPC. Шо это за хуйня? Мне весь проект перелопачивать ради того, чтобы в одном окошечке реализовать возможность регулировки прозрачности цвета?
Ну пиздец.
>я должен наследовать DependencyObject или Framework Element
нет. наследовать Freezable
твое
<Binding.Converter>
<cnv:OpacityConverter Reference="{Binding TestColor}" />
</Binding.Converter>
ругается же как
System.Windows.Data Error: 2 : Cannot find governing FrameworkElement or FrameworkContentElement for target element. BindingExpression:Path=TestColor; DataItem=null; target element is 'OpacityConverter' (HashCode=60429346); target property is 'Reference' (type 'Color')
если конвертер вынести в ресурсы
<cnv:OpacityConverter x:Key="OpacityConverter" Reference="{Binding TestColor, Mode=OneWay}" />
и использовать
Text="{Binding TestColor, Mode=TwoWay, UpdateSourceTrigger=PropertyChanged, Converter={StaticResource OpacityConverter}}"
то все работает.
>если конвертер вынести в ресурсы
А если у меня таких 100500 окон, то в ресурсах я должен создать 100500 экземпляров конвертеров?
Впрочем мне все равно придется делать общий конвертер с правым окном. Спасибо за помощь!
есть проблема
в теории ты можешь использовать MarkupExtension чтобы передавать цвет как параметр, но тогда ты не сможешь передать этот цвет как биндинг
а наследоваться от 2х классов Freezable и MarkupExtension ты не можешь
тут нужно велосипедиь.
А зачем мне теперь MarkupExtension?
Freezable вполне устраивает. Я щас вывел конвертер в ресурсы, сделаю его общим для двух текстбоксов. А при помощи ConverterParameter буду маркировать какой тип данных конвертер получает, ну и дальше парсить нужным образом.
Но тогда непонятно как это будет работать в обратную сторону. Походу придется делать конвертер для каждого окна. Для каких-то единичных ситуаций может и подойдет, но не для таблицы с кучей цветов.
Либо надо внутри держать какой-то словарь, а ключ передавать тем же параметром. Выглядит как хуета.
MarkupExtension нужен тем кто "не хочу я в ресурсах конвертер обьявлять и статик конвертер тоже не хочу, хочу чтобы на месте"
и там все хорошо пока не захочется передать параметр который нужно дополнительно биндить.
Судя по вопросу ты еще в реакт/фронт не вкатюлился, так что ответ столько же сколько с нуля
Ну. Если есть хотя бы общие представления о БД, многопоточности, типах, то не то чтобы прям.
Говорю правда с другой стороны, когда нужно было из бека шарпа стать временно фуллстеком.
Да я решил что мне неинтересно ебашить фронт, меня типа учат огромному количеству инфы, но я все еще не понимаю нахуя мне это надо.
ПЛюс милиард библиотек
реакт редакс мобх тайпскирпт таилвинд вуе ангуляр
почему так сложно, вы долбаебы чтоли?
На беке тебя вообще инфой засыпит чел, а если не осилишь, так еще фулстеком придется работать в мелкоконторах.
Ну а где не засыпет то в кодинге? Другое дело чтобы было интересно в этом всем копаться, и я видел какую-то финальную цель.
Но когда я поделил их на две стакпанели нихуя не работает. Почему так?
Дошло кажись, у меня радиокнопки, они одним стэком считаются.
>год опыта коммерческой разработки
>впф
Это не считается, такой попуск на собесе устроят, заснуть потом не сможешь
Конечно. Ты же в бэк собираешся, а там твой впф-опыт почти никому не уперся.
>Хочешь верь, хочешь нет, но в мире остаётся огромное количество заказчиков программного обеспечения
Ну-ка, хотя бы парочку нормальных контор с открытыми вакансиями приведи.
Чо чулавека пугаешь. Ваше крудошлепство дебил освоит за неделю и уже мидл.
Мне странно, что до сих пор джаву рекомендуют как язык для бэка, разве он не хуже шарпа?
бэком раньше не интересовался вообще, не бейте
1) Во первых конкретные примеры, а то я тоже могу про 'массы' говорить. Во вторых, в большинстве таких контор 'разработчиков аналогов' ты будешь хуй сосать вместо зарплаты.
2) Тут уже интереснее, только ты все равно обосрался. Компас написан на плюсах, на шарпе там только плагины можно для него делать. И то в подавляющем большинстве они все на делфях сделаны (знаю т.к. сам писал). Ну и в аскон хуй ты попадешь без знания плюсов и хорошей математической базы (это если на сам движок), либо хорошей предметной базы (вроде конструкторской или ТМ), а это почти всегда вышка или неебический опыт. С годом ВПФ-а там нехуй делать.
>Ваше крудошлепство дебил освоит за неделю и уже мидл.
Угу, круды. А потом тебе дают таску вроде "подписание xml по хитровыебанному ГОСТу, с оригинальным алгоритмом каноникализации и под линукс" со сроком хорошо если хотя бы в пару недель. Или интеграцию с каким либо сервисом с каким то хитровыебаным форматом мутантом jsonrpc, resta или еще хуй пойми чего. Где хорошо если хотя бы часть API описана.
А все круды уже давно автоматои парой строчек делаются наследованием от абстрактных классов.
Шарп норм, на джаву очень похож.
Я в том году вкатился, до этого учил джаву года полтора.
Базу какую-то на джаве выучил, начал Spring изучать, прошел курс на udemy где-то наполовину - параллельно для общего развития потихоньку изучал JS, и знакомый порекомендовал ангуляр потыкать - там его каким-то знакомым требовался на ангуляр разработчик.
В итоге вкатился на фронт/фулстэк (в другую контору), JS по сути выучил через ООПшную логику TypeScript и Angular, а бэк тут на шарпе.
Шарпаны. А что можно почитать по функциональному подходу в C#? Ну и вообще базу по функциональщине?
Ну я вот тоже хочу фуллстэк, но нет уверенности, что шарп подойдет, но судя по вакансиям все норм. Изначально думал, что буду его для геймдева юзать, но игры вообще не мое как оказалось, хочу на сайтики перейти, но пока вообще ничего в них не понимаю, поэтому может и спрашиваю тупые вопросы.
Просто смотрю на вакансии для бека и там требуют C#, HTML, CSS, а для фронта вакансий меньше и зп меньше, требования те же, но без C#, лол.
типичные требования для вката в 2023, м
На каждом проекте свои критерии для джунов и миддлов. Где-то миддлом можно быть с 0.5 годами опыта (в основном мелкие проекты в стартапах), где-то не меньше 5 (огромный проект с кучей разрабов и энтерпрайзе).
Если это зарубежная вакансия, то да.
Это в РФ основной принцип: "Маши крыльями - или сдохнешь". И вчерашний джун с годом опыта уже через год может в соло ебашить микросервисы, чтобы не вылететь на мороз.
А там все крайне неспешно (настолько, что готов поспорить, что в данной вакансии подразумевается еще .NetFramework и никакого Core). Там чел может спокойно сидеть в офисе года 2...3 и ничего кроме простых задач ему не доверят, просто потому что не по статусу и недостаточно задниц вылизано.
>но судя по вакансиям все норм
Ну это от региона кстати сильно зависит. Смотри по вакансиям и стеку необходимых технологий - это и учи.
Для фулстэка необходимый минимум что надо знать - это основы HTML (DOM) и CSS, SQL очень важен, какой-либо из JS/TS фреймворков (React, Angular, Vue), основы работы протокола HTTP, ну и собственно сам шарп (ASP.NET/ASP.NET Core).
И, что ОЧЕНЬ важно (лично для меня было) - освой дебаг. Чтобы прям в Visual Studio или дебаг-консоли браузера ты шел по строкам, смотрел что в какую переменную поступает, как обрабатывается и как хранится в памяти.
Рекомендую на базе (философствования по поводу ООП и прочий leetcode) сильно долго не засиживаться, как только начнешь более-менее разбираться - учи фреймворки и пытайся собрать на практике рабочий пет-проект из разных языков и технологий. На этом этапе не помешает освоить Git (его впрочем тебе и так в любом курсе впарят за компанию).
Чтобы изучить любую технологию/фреймворк - на старте выбери какую-нибудь книгу, интернет- или видео-курс (не особо важно какой, тут главное системность и чтобы с упражнениями самостоятельными) и иди по ним. Пройди хотя бы наполовину.
Чем дальше будешь по этому пути идти - тем четче будешь видеть дальнейший путь.
Добра.
Спасибо, анончик, добра тебе. У меня план вот ровно такой и был, как ты написал, но теперь стал чуть более структурированный. Просто иногда читаю статьи и там совсем не упоминают C#, либо пишут, что он для сложных и больших проектов, а не для небольших сайтов, это так? Хотя не думаю, что это играет сильную роль.
А фулстэк меня интересует только потому, что мне отчасти интересен фронтенд и дизайн, так как есть навыки в художественной области, но понимаю, что вообще не хочу связывать всю профессию с этим, меня бэк намного больше привлекает. Но при этом буду совсем горевать, если мне нужно будет всю жизнь только с серверной стороны работать. Очень люблю подбирать цвета, шрифты, формы, у меня прям гармонично это получается, но вот на постоянку такое - meh.
> Хочу перекатиться из ноды в шарпы. Уже какое-то время трогаю аспнет + ef. Что ещё посмотреть? Что читать?
Продолжай тыкать asp.net, ef. У майков отличная документация https://learn.microsoft.com/en-us/aspnet/core/getting-started/?view=aspnetcore-7.0&tabs=windows , где и гайды, и fundamentals.
А дальше по роадмапам иди (https://github.com/Elfocrash/.NET-Backend-Developer-Roadmap), и тыкай разные библиотеки (automapper, swagger, serilog, xunit etc).
> Нужен ли CLR via C#?
Книги по asp/ef/c# такое, инфа на сайте все-равно быстрее обновится, CLR via C# уже про базу C# и рантайма, читать смысла не много на первых порах.
> Даёт ли опыт 3 года на ноде+рякт+тс какой-то плюс? Даёт ли опыт с плюсами какой-то плюс?
Ну TS похож, т.к. 1 человек проектировал, из фреймворков angular много концепций asp имеет, di например. Опыт просто из бека поможет.
В сравнении с плюсами, меньше ебки и писать приятнее.
> Насколько шарп востребован на западе вообще?
Ну в энтерпрайзе больше джавы, но c# достаточно, работы хватит.
>
>automapper, swagger, serilog, xunit etc
Ну из этого всего только serilog не трогал. А так всякие там newtonsoft, автофак и прочие хз бест ли но практисы пробовал.
А так общее знание бека, тса и плюсов помогает люто. Хочу заспидранить нужную для прохождения собеса теорию и начинать вкатываться.
Вот смотрите. Я таки решил, что нехуй соединению знать че там за протокол прикладной, все такое.
Но вот решил я сделать вот такую бяку:
public abstract class ProtocolContext<TProtocol, TMessage, TContext> :
where TProtocol : IProtocol<TMessage,TContext>, new()
where TContext : ProtocolContext<TProtocol, TMessage, TContext>
{
static readonly TProtocol _protocol = new();
private TContext _context;
public Task<TMessage> Rec() => _protocol.Rec((TContext) this)
public Task<TMessage> Send(TMessage message) => _protocol.Send(message, (TContext) this)
}
И в случае реализации оно выглядит так:
public class MyProtocolContext : ProtocolContext<MyProtocol, MyMessage, MyProtocolContext>
{}
Чет смотрится как говно. И уверен что нарушает какие-нибудь принципы солид.
Особенно если смотреть со стороны клиента, потому что вот эту вот бяку - приходится оборачивать в MyClientProtocolWrapper который уже будет получать MyProtocolContext.
Короче. Может быть у вас есть лучше идеи как это все сделать?
А ты не думал, что изначальная ошибка в том, что ты пытаешься совместить не совмещаемое? Я в таком случае разделяю когда на разные модули, которые друг о друге ничего не знают.
Ну. Думал.
Просто как. Моя идея-то в чем.
Вот в чем.
В конечном итоге оно должно выглядеть примерно так:
var dispatcher = new MyProtocolDispatcher();
var server = new ServerBuilder()
.UseTcpListener(0, 80)
.UseConnectionLimit(100500)
.UseProtocol<MySupperDupperProtocol>()
.UseHeartbeatHandler( async (con, serverContext) => { if(DateTime.Now - con.LastActive > Timespan.FromMinute(1)){
var messagePing = new PingMessage();
var protocol = serverContext.GetProtocol();
await protocol.Send(messagePing, connection);
}
})
.UseConnectionHandler(new ConnectionHandlerBuilder((connection, serverContext) => {
var protocol = serverContext.GetProtocol();
while(connection.IsOpen){
var request = protocol.Rec(connection);
await dispatcher.Dispatch(request, connection);
}
}))
.Build();
await server.Run();
И типа хотим, используем формы, хотим - консолькой, хотим - присобачиваем это к ASP.Net и управляем через веб-интерфейс сервером, который присобачиваем к ASP.Net с его инфраструктурой.
>Ну из этого всего только serilog не трогал.
Еще NLog для верности наверни. Он примерно так же часто как серилог встречается.
Надо обязательно прочитать несколько талмудов про логгеры, а то не перезвонят.
В 2023 чтобы вкатиться надо обязательно качественно освоить пайплайн из логгирования - выгрузки в Elasticsearch - тренировки GPT модели на поступивших из логов данных.
Не, на собесах тебя максимум спросят с какими логгерами ты работал и все. А вот на реальной работе тебя сразу ссаными тряпками погонят, если ты в логгирование не умеешь. А NLog и Serilog - это фактически уже стандарты индустрии.
>тебя сразу ссаными тряпками погонят, если ты в логгирование не умеешь
Как только объяснишь нахуй они нужны
Байтом конечно же.
В шарпе нет указания что это байт кроме явного каста
>Как только объяснишь нахуй они нужны
Когда проебешь транзакцию клиента на пару лямов и в твоей системе не будет и следа от запросов, тебе доступно объяснят зачем нужно логгирование.
Логично же. В системе ориентированной преимущественно на x32/x64 все должно по умолчанию в байты каститься. Все для удобства байтоебов.
Главное не логировать персональные данные. А то так можно будет проебать уже не пару лямов, а пару лярдов.
Для предотвращения такой хуйни у меня проект юзает блокчейн. Повторю свой вопрос - зачем мне логгирование?
У тамошних объектов сначала идут общие поля для всех:
Id, Type, Category, Price и т.п.
Type указывает как раз на тип объекта. В зависимости от типа объекта могут быть дополнительные поля.
В C# мне нужно объявить базовый класс и наследующие классы. Но вот как их правильно создать из json? Сначала вручную чекать Type, а потом в зависимости от него создавать нужны экземпляр класса?
>блокчейн
Во первых: для некоторых вещей блокчейн оверхед.
Во вторых: ты в него вообще все говно пихаешь что-ли? У тебя может ошибка на уровне инфраструктуры выскочить еще до того как до твоего блокчейна доберется или уже после него. Ты как потом разбираться будешь где у тебя что упало?
В третьих:
>зачем мне
Затем, что иди нахуй, вот зачем.
>ты в него вообще все говно пихаешь что-ли?
Нет. Как раз таки только биллинг инфу которого потерять нельзя.
>Затем, что иди нахуй, вот зачем.
Причина подрыва?
>Причина подрыва?
Нога болит после операции. Вообще всех ненавижу сейчас.
Народ, а есть у кого примеры использования Telegram.Bot под Asp.Net, но только не на вебхуках, а с использованием long poling ?
Судя по российской практике утечек баз - максимум штраф тысяч 50 лол.
И что делать, если я в сеттингах своего приложения захочу поменять хоткей? Как применить изменения без перезагрузки всего приложения?
>В зависимости от типа объекта могут быть дополнительные поля.
Что это такое вообще? Ты через жопу сделал наследование базового класса? У тебя по итогу должен быть класс, который может храниться в твоем массиве как Object или как тот же базовый класс, или как интерфейс.
Джейсон конвертер смотрит этот обджект и парсит его со всеми доступными свойствами.
>дополнительные поля
Поля и статические поля, приватные свойства конвертер вроде пропускает мимо
Чтобы запретить какое-то свойство от парсинга, юзается атрибут [JsonIgnore]
Через List<object> и темплейты? Или вместо List<object> лучше как на пике 2? Если пик 2, то не выглядит ли он как говно?
Все что в голову пришло, это сделать обертку поверх KeyGesture и сделать те же свойства, которые будут ретранслировать свойства из экземпляра KeyGesture. Заодно свойства можно сделать INPC.
Пока не знаю поможет ли это во всех ситуациях, ведь некоторые элементы требуют именно класс KeyGesture.
Разве никому в голову не приходила идея менять хоткеи в рантайме?
Все что я видел — это очистка InputGestureCollection, но это какой-то бред или я чего-то не понимаю. Привязка существует к свойству конкретного экземпляра KeyGesture, очищая InputGestureCollection я этот экземпляр удаляю и биндинг слетает.
Когда я делал свое дерево, у меня Group сам по себе был коллекцией. Я юзал MVVM, поэтому Group наследовала ObsrtvableCollection, чтобы можно было биндить. А сам факт добавления в Group чего либо, говорит что внутри собсно есть другие элементы.
Ничего не мешает в эту коллекцию добавить экземпляр новой коллекции Group — так выстраивается иерархия.
По итогу, дереву я скармливал ровно один элемент — Group, который был корнем всей остальной иерархии. Внутри этой корневой папки были дургие папки, а внутри этих папок еще папки.
Если ты юзать MVVM, то в TreeView там есть два темплейта
HierarchicalDataTemplate и DataTemplate. Первый распознает группы, а второй итемы.
Конечно же надо скормить в DataType тип нужного класса, к примеру
<HierarchicalDataTemplate DataType="{x:Type ns:Group}" >
тут твой темплейт
</HierarchicalDataTemplate>
<DataTemplate DataType="{x:Type ns:Item}" >
тут твой темплейт
</HierarchicalDataTemplate>
И после этого автоматом TreeView все распознает.
>>2635522
Дальше, что это за свойство Group? Родительская группа?
Пиши Parent как для Item, так и для Group. Лучше, чтобы оба реализовали единый интерфейс (назовем его INode) со свойством Parent.
Далее, ты должен переопределить метод Add и Remove в классе Group (который у тебя будет наследовать коллекцию). В этих методах ты будешь автоматом заполнять то самое свойство Parent, или же удалять. Это позволит тебе в дальнейшем не париться по поводу контроля Parent.
После этого у тебя все встанет на свои метса. А свойства Groups и Items — хуйня из под коня, никакой универсальности. А что будет если ты захочешь добавить папку или еще какой элемент в иерархию? Что, будешь добавлять новое свойство с коллекцией этих элементов? Я уж молчу по поводу сканирования всей этой хуеты в будущем.
Ща у тебя группа и итем это совершенно не родственные элементы. А должно быть так, что (возвращаясь к началу поста) все элементы иерархии в основе своей ноды (INode). Тогда ты сможешь скармливать своей группе новые элементы, если они вдруг появятся в будущем.
>Пикрил 2, имя базового класса
I have a Item, I have a Group
Ammm...
>ItemOrGroup
I have a ItemOrGroup, I have a HierarchyElement
Ammm...
ItemOrGroupAsHierarchyElement
I have a YourMother, I have a Sana, I have a Class
Ammm...
ItemOrGrouprOrYourMotherOrSanaAsHierarchyElementAsClass
Назови базовый элемент нодой.
>ItemOrGrouprOrYourMotherOrSanaAsHierarchyElementAsClass
Ну... В своё оправдание могу сказать, что у меня это всё как хобби и больше классов кроме этих двух не будет. Сначала я хотел сделать по-другому, но потом решил, что будет просто перебор ради двух классов, который ещё и когда-нибудь в будущем только усложнит понимание при необходимости поковыряться в этом говне.
>>2635522
>>2635546
Item и Group для примера, настоящие классы называются по-другому но наверняка всё равно тупо, но я пытаюсь... и находятся в другом проекте, там уже всё сделано (ну или почти всё), а хуйня на втором пике чтобы было понятно.
>Дальше, что это за свойство Group? Родительская группа?
Только как объект для группировки объектов класса-прообраза Item. Ни для чего больше. Типа как папки. В Item свойство Group вообще можно убрать.
>Пиши Parent как для Item, так и для Group. Лучше, чтобы оба реализовали единый интерфейс (назовем его INode) со свойством Parent.
>Далее, ты должен переопределить метод Add и Remove в классе Group (который у тебя будет наследовать коллекцию). В этих методах ты будешь автоматом заполнять то самое свойство Parent, или же удалять. Это позволит тебе в дальнейшем не париться по поводу контроля Parent.
Item и Group находятся в законченном проекте (библиотеке). Я не сомневаюсь, что он говно, но какой есть. И более того - мне кажется, что там это будет лишнее.
>В своё оправдание могу сказать, что у меня это всё как хобби и больше классов кроме этих двух не будет.
Что пилишь?
Пока что хочу записную книжку. Пробую так и сяк, сначала пытался смотреть, как делать "правильно" (домены и всё такое), но вопросов появлялось овердохуя и забил, стал делать как придумается. Херовастая память и постоянно хуевое состояние из-за недосыпа и неудобного рабочего места на работе, и идея записной книжки появилась задолго до того, как увлёкся программированием.
>стал делать как придумается
Сейм щит. Переделываю свой проект третий раз, пока проект не стал хоть как-то походить на "как надо".
>>2635645
>Типа как папки.
Т.е. родительской папки?
> И более того - мне кажется, что там это будет лишнее.
Кхм ... это тебя щас кажется, а потом мы имеем вот это
>Я не сомневаюсь, что он говно, но какой есть.
... ибо прошлый проект ты пилил абсолютно по такому же принципу.
Ну что тут сказать? Наверно придется как-то "вручную" заполнять дерево. Смотри, тебе же не надо сканировать ВСЁ дерево вглубь? Ты выводишь на экран только ближайший под-уровень папок, тебе должно быть поебать сколько там внутри вложенных элементов.
По двойному клику условной папки, ты выводишь содержимое папки не далее одного уровня. Понимаш? Т.е. список Groups и Items. Всё.
Можно добавить свойство IsExpanded, чтобы хранить все раскрытые ноды.
Там тэги (Item) и их группы/наборы. Так что выводить надо всё будет всё. А ещё там должны быть чекбоксы у каждого тэга и группы - у тэгов для присвоения к записям и потом фильтрации, у групп - чтобы включать/отключать всё, что вложено.
>>2635713
Вроде да.
Ну тогда только рекурсия.
Функция должна сканировать один уровень вложенности, потом применяться к каждой найденной папке для поиска вложенности, пока не дойдет до упора.
Смотри алгоритмы поиска в глубину и поиска в ширину.
Учись делать миграции, code-first это лучшее что придумало человечество
Мало того, что у него ридонли свойства, так он еще не поддерживает простые хоткеи, уровня "B", или "Ctrl+B".
Если первое еще как-то логично т.к. при наборе теста в каком нибудь текстбоксе сработает хоткей, то "второе не является жестом".
Что такое жест? Нахуй он нужен? Или это та самая блядская система VS уровня "Ctrl+B, Ctrl+D", которую будет нажимать только солевой наркоман?
Но трясешься тут ты иначе зачем коупинг выше? Сиди спокойно на своей джаве и фикси баги. Когда совсем время прижмет и кабан заставит тебя переписывать многолетнее джава легаси на дотнет то просто уйдешь в другой энтерпрайзный загон догнивать
Слит. Также как слили джавовых бездарей в такскоме и тиньке, переписав их обмякшее под нагрузкой джава дерьмо на дотнет)
1.1. Используй ::.
1.2. Кучу раз уже обсуждали почему Олман пизже чем K&R. И всегда основной аргумент приверженцев жаба-стиля: "Ряя-яя. Байты дорогие. Лишняя строчка глаза режет".
1.3. Ну сокращение и что. Ты только что плакался, что тебе лишняя строка глаза режет, но всякие extends/implements типа норм.
1.4, 1.5 - пустые доебы уровня скобок, даже не до семантики, а до общепринятого кодстайла языка.
2.1. Никогда не понимал, горения жабаебов с get/set. Максимально удобная штука позволяющая нормально инкапсулировать логику внутри класса.
2.2. Твои сведения устарели. Уже года 3 как есть. Правда уверен, что тут же будет высер на тему "ваши рекорды, совсем не рекорды", но да и похуй на тебя.
2.3. Лень разбирать что это в джаве, но подозреваю, что есть. В шарпе дохуя всего связанного с многопоточностью, включая всякие семафоры, локи-хуеки и прочую лабуду. Так что и такая хуета думаю найдется. Плюс в джаве до сих пор нет нормального аналога async/await, а это по моему намного сильнее перевешивает.
2.4., 3. 4.
Ты там немчинского обсмотрелся что-ли? Как там в 2016-м? Даже коментировать такую хуйню не буду.
PS C:\Trash\С#\project> dotnet --version
7.0.201
PS C:\Trash\С#\project> dotnet new console
При создании этого шаблона будут внесены изменения в существующие файлы:
Перезаписать ./project.csproj
Перезаписать ./Program.cs
Чтобы создать шаблон в любом случае, выполните команду с параметром "--force":
dotnet new console --force
Дополнительные сведения о коде выхода см. на странице https://aka.ms/templating-exit-codes#73
PS C:\Trash\С#\project> dotnet new console --force
Шаблон "Консольное приложение" успешно создан.
Идет обработка действий после создания...
Восстановление C:\Trash\С#\project\project.csproj:
Определение проектов для восстановления...
Все проекты обновлены для восстановления.
Восстановление выполнено.
Никаких файлов в папке создано не было. Что делать?
Ну. Т.е. я поясню че я делаю.
У меня есть протокол. Вернее несколько.
В протоколе - есть сообщения. Все вроде понятненько.
Ну дык вот. Меня - остоебенело, что если в протоколе китайцы добавляют новый тип сообщения - приходится лезть в огромный switch и там создавать обработчик. Накидывать ему сервисы, что нужны для работы, вот это вот все.
Я решил, что будет удобнее, если будет просто ProtocolController, в котором я просто напишу новый метод по обработке сообщения, и оно типа само вот так вот "зерегистрируется".
Но конечно смущает, что 1. рефлексия. 2. Само решение - кастрированное, оно предполагает, что ответ я буду из контроллера слать, а параметры метода контроллера - будут содержать только сервисы, которые нужны мне для работы.
К примеру, мне через IMAP нужно загрузить загрузить файлы с почты и показать юзеру папки с почты.
Это все в отдельный класс запихнуть и использовать как репозиторий или прям в презентере весь функционал реализовать?
Тоже самое с яндекс диском, нужно загружать файлы на диск, можно, конечно, напрямую в презентере все написать, но меня как-то коробит от этого.
Вообще не понял о чем ты.
Типичная структура современного проекта на шарпе, примерно следующая
Работа с апи - это просто вьюшка в старых терминах, т.е. тебе приходит запрос на роут, ты его передаешь в сервис, потом, если надо, от сервиса результат оборачиваешь в DTO и отдаешь клиенту.
Если ты типа оборачиваешь чужое апи, то делаешь абсолютно так же, оборачиваешь чужое апи в такой же сервис, на своей стороне - делаешь апи чтобы к тебе уже обращались, ты дергаешь сервис, сервис дергает чужое апи, результат, если надо - отдаешь клиенту, клиент - уже рисует че там ему надо на базе вашего контракта по поводу дтошек.
//afterCreate.sql
INSERT into dbo.Sklad("Название", "Масса (кг)", "Объем (М²)", "Количество (шт)")
VALUES
('Говно', 1, 10, 1000)
Ну, собственно можешь это прямо в скрипт по созданию базы вставить, сразу после того как ключи всякие настроил.
Обернуть все в IF DB NOT EXIST и радоваться. При первом старте - все заполнишь как тебе надо.
Деды так делали, и ты так делай.
А в контексте EF - можешь просто modelBuilder.Entity<Govno>().HasData(...), но это не тру и вообще, для пидоров
Если я "Вдохновляюсь" теперь-то открытым кодом майков в закрытых проектах, могут ли от этого быть проблемы?
Типа блин. Вот иногда же смотришь как у них там че сделано, задумываешься, чому не делать так же, раз уж они так делают.
Ну, собственно, некоторые куски из памяти восстанавливаю почти 1 в 1, пусть и для своего случая.
Смущает.
>Смущает.
Смущаться будешь когда тебя за дрочкой на что-нибудь непотребное застукают. А в программировании вся суть состоит в том, что нехуй дважды делать работу которую уже сделали. Если кто-то уже сделал что-то хорошо, то возьми это и используй, если можешь - улучши.
Если тебя смущает правовой вопрос. То в РФ ты со своим кодом нахуй никому не нужен. Здесь тебя в первую очередь выебут за нелицензионный автокад или 1С (даже если у тебя их нет, кек). А за рубежом прав тот у кого больше бабок.
>2.3. Отсутствие виртуальных тредов.
Так их и в джаве нет, то что есть к проду не готово
Еще смешнее с несуществующими виртуальными тредами джавы, что оракл проигнорировал комьюнити, которое десять лет потратило на запил годных инструментов и библиотек для реактивного программирования. Типа им виднее какой путь лучше
1.1 ну отступы можно не делать, хотя я вот все равно делаю. привычка (при этом на остальных языках отступы не делаю)
1.2 поддерживаю.
1.3 чушь. слова это уродливо. сравни бейсик и шарп. бейсик нереально читать ибо глазу легко понять символ, а вот слово нужно читать. Поэтому и на дорогах знаки это символы, а не текст (текст только там, где без него нельзя)
1.4 как раз наоборот - знаешь что обращаешься к интерфейсу и это правильно. Подчеркиваешь что тебе неважно кто там, важно что он умеет.
1.5 фломастеры. бесит только психов. сам пишу на многих языках и в каждом языке свои правила и корежит читать когда левые правила несут в язык.
2.1 так то ломбок принесли ибо даже жависты (которые законсервированные динозавры) стали ныть что "ну сколько можно писать getXXX/setXXX в 21 веке). И семантика аннотациями имхо более уродлива чем гет/сет.
2.2 ты из какого года пишешь?
2.4 ВИНформс прибит к вин (удивительно )))
Нахуй вы это включаете.
> Неймспейсы. Полный пиздец. Рассинхрон с пакетами
Так неймспейс нужны для другого. Как раз они - позволяют соблюдать семантику, когда ты можешь на разных уровнях приложения.
А вот пакеты в джаве - полное говно.
> лишние отступы
Из какого года ты пишешь? Уже года 3 как - можно без отступов неймспейсы делать.
> проблемы с уникальностью названий
Как и джаве с ее пакетами, лол.
> Перенос { на новую строку
Вкусовщина. При этом - хочешь, используй Mono-стайлгайд, они - как раз не переносили.
> IZalupa как название интерфейса по дефолту
Да, ведь лучше у тебя будет интрефейс List, а потом дефолтная имплементация: ListDefault. Да? Да? Да? Да? Лучше будет IList и как человек ты будешь использовать List
> Названия методов с большой буквыIZalupa как название интерфейса по дефолту
Вкусовщина и так же зависит от конторы. У нас вот вообще другая логика организации: Все что публично - с большой, что приватно - с маленькой. При чем тут шарп вообще - хуй знает.
> Наличие бойлерплейта
Даааа. Как там очередной раз реализовывать обсервера? А, ну да, ты же поставишь пакет чей-нибудь, язык-то не предусматривает)))
> Отсутствие record
Из какого года пишешь? Есть рекорды.
> Отсутствие виртуальных тредов
Не помню про это. Может быть уже съебался, когда оно появилось.
> Прибитость гвоздями к винде
Из какого года пишешь? Буквально за 7 лет что я на шарп перебрался, ни одного приложения, которое идет потребителю - не писалось на винде и крутилось в основном на линуксах, для винды - только отдельный установочный пакет делался.
>Экосистема. У петушарпа позорная экосистема
Вот, единственный реально важный доеб. Экосистема в целом - в джаве в разы лучше. На выбор и системы сборок разные, и куча пакетов под любой вкус.
Другое дело, что это порождает ситуацию, когда: проект еще под ant сделали, чел что писал его - охуеть преисполнился и съебался в закат, теперь никто из новых сотрудников - не в состоянии собрать это говно. На шарпе - я открываю проект написанный в 2003м, студия мне предлагает обновить, конечно оно сразу не собирается, но часик посидел, поправил где надо - все, оно собирается и работает. В джаве - перенести что-то древнее, это просто такой-то экспириенс, что ебись оно в сраку, кажется что проще переписать эти ебучие 200к строк на шарп и не париться больше.
> Свобода и распределённость
Тоже странный доеб. Код открыт, спецификация - есть. Есть некоторый обосрамс, который случился с переходом с .net framework на .net core, когда половину всего отвалилось, но уже пару лет как - почти все что надо - перетащилось. А что не перетащилось - перетаскивается. При этом с открытием кода .net - резко подскочил средний уровень кода у комьюнити, аж радостно.
А теперь - мои притенении к жаве.
1. В файле - один нормальный класс. Просто 11/10 решение. Из-за этого вырастают уродливые решения, когда в класс - вкалдывают еще классы, потому что - блядь, ну, кхем, кхем, ну, АРХИТЕКТУРА, кхем.
2. Куча бойлерплейта. Каждый новый проект - начинается либо с подтягивания библиотек с этим самым бойлерплейтом, либо с реализации хуйни четырех пидорасов.
3. Отсутствие лямбд. Тут - я могу спиздеть. Когда я сваливал - не было. Было пиздец как охуенно делать класс на каждый чих. Но вроде читал, что лямбды появились
4. Отсутствие async-await. Как же охуенно - тредпулом пользоваться, пиздец просто, дайте мне тредпул, и колбек в него положить. Уууу. Блядь. Тредпул наше все! А если мне нужно бекграунд таску намутить - дайте мне Runnable. Уууу. Как же бе Runnable жить-то?
5. Зоопарк. Из-за этого зоопарка - в принципе ты не соберешь проект без IDE. Уже писал выше, как охуенно, когда дед, который знал, как собирать - съебался в закат, и больше никто в компании - не знает, как собрать то что он писал, чтобы пофиксить баг или фичу впилилть.
6. Тяжеловесность. Это просто пиздец. Я помню, как на мине писал сервер для джавы. 5к коннектов - ХУЯК, блядь, 4 гига вынь да полож. На шарпе - тасками такой же сервер - для 10к соединений 200МБ жрет и живет спокойно.
7. Без коммунити - ты в принципе не способен чет нормальное делать. Стандартный набор того что есть - крайне ущербен. В шарпе - у тебя уже есть почти все, что нужно для нормальной жизни из коробки.
Чувачок, твой оригинальный лист 'недостатков' ничем от "нинужна" и "яскозал" не отличается. Так что завали и отползи нахуй.
Просто Y детектит, так же детектит "Ctrl+Shift+Y", а это не хочет.
>>2638241
Бля, этот текстбокс, а у него куча своих внутренних хоткеев. Понял, когда не отработал Delete, хотя на других элементах точно работал.
Из жавы куда-то делись конструкторы? Та не пизди.
А если хочешь прокидывать зависимости без использования конструкторов в шарпе - берешь и юзаешь рефлексию. Никто не мешает.
Опять же, другое дело, что код джавовский, для ньюфага из-за всей этой мумба-юмба магии становится этой самой магией. А стектрейс при ошибке - так вообще в джава - это рофл какой-то.
Или искать ошибку, когда у тебя метод, если верить ИДЕ - вызывается 0 раз, но блядь, вот почему-то вызывается, ебись как хочешь)))
Зато при упоминании свойства - такой вот сектант либо зашипит про ненужность, либо магический атрибут вспомнит. Забывая, что сама по себе жава - тот еще кастрированный кусок добра.
Я бы понял, если бы ты котлин вспоминал. Он - да, реально качественный шаг вперед. Но джава. Это рофл какой-то же. Медленная, прожорливая, еще и в своей основе - кривая в дизайне, а потому - кривоту - приходится преодолевать кучей костылей.
Хуй пойми че ты сказать хочешь.
Любая магия в программировании - зло. Ты потом заебешься отлаживать и искать причину того, что у тебя чет в рантайме падает или течет как сука. И самое веселое, когда это происходит из-за чужой магической приблуды.
Посоветуйте в какую сторону гуглить
Quarz - библиотека для запуска периодических задач (jobs).
Для контроля времени запуска задач можно использовать Cron Expressions. Например в твоем случае для "запуск каждый день в 9 утра" крон будет выглядеть вот так "0 0 9 ?". Как хранить в бд решай сам. Можешь непосредственно в таком виде хранить или преобразовывать непосредственно перед настройкой джобы.
Когда у тебя над методом/полем висит магический атрибут, и он за тебя чет там делает. А в широком смысле - любая хуйня, которая делает что-то неявно, скрыто от твоего взгляда и без возможности повлиять на это без жопной боли.
В шарпе - такая магия - это роутинг запросов.
В жаве - это спринговская хуйня и максимально - CrudRepository<Govno, Zalupa>.
>вот так "0 0 9 ?"
Сорян, символы сожрались. На картинке правильный вариант.
А я несколько лет пишу на жабе и плююсь от принятого здесь способа расстановки скобочек. Был бы у меня выбор, расставлял бы их как в шарпе.
Не выёбывайся, фигурные скобки с новой строки не проходят ревью, и хуй что я сделаю.
Я бы и интерфейсы называл с I, всяко лучше, чем уродливые Impl.
Вроде джавист, а такую хуйню несёшь, аж стыдно за коллег по профессии.
Не только про них, но и них в том числе.
Отличается тем, что на деле - это магия. Я, как программист - не знаю что это за метаданные, где они будут дергаться, зачем. Я теряю контроль. Как программист - я хочу писать хороший, высокопроизводительный код. Чтобы писать такой код, я должен понимать, что с тем кодом, который я пишу происходит. В идеале до уровня ассемблера или бинарного кода, который получится в результате. Когда в дело вступает магия, я просто отдаю все на откуп каких-то других людей, и надеюсь, что они сделали все правильно. А на деле - там может быть портянка из автосгенерированного кода, который никто не знает как работает, и вот теперь - ебись как хочешь.
Я бы вообще, будь моя воля, большую часть плюшек и шарпа бы поубирал, типа асинк-эвейтов, всяких неявных захватываний переменных в лямбдах и прочего мусора. Вот был бы си, но без проблем с безопасностью, я бы всеми силами его проталкивал где только можно. Максимум, который нужно в си добавить - классы, женерики, импорты-экспорты человеческие. Собственно - все.
Альтернативой Quartz - Hangfire. Мне оно больше понравилось. Проще в настройке, работает отлично, есть дашборда из коробки.
Ну а если тебе не хочется тянуть чужую систему, то можно было бы простенький велосипедик.
Дергать базу раз в минуту - ничего плохого нет, что Hangfire что Quartz - делают именно это, просто за тебя. Базы сейчас - быстрые что пиздец и рассчитаны на тысячи-миллионы запросов чтения в секунду.
Но если не хочется каждую минуту.
Тебе просто нужно сделать сущность очереди, в которой ты рассчитываешь следующее время для старта задачи и метку добавлять. При инициализации сервиса - проверяешь, есть ли там задачи, которые надо было выполнить с прошлого раза. Если нету - ищешь запись с самой близкой меткой времени, спишь до этого времени, потом - достаешь все что тебе надо выполнить - выполняешь, обновляешь время следущего запуска, кладешь в базу, находишь блиджайшую метку времени к текущему времени - и спишь до нее. Повторяешь пока приложение не завершится.
Примерно так выглядеть запись будет:
pubic class Job{
public int Id { get; set; }
//чтобы когда грохнули юзера - все его джобы - ебнулись вместе с ним
public User User { get; set; }
// апи которое дергаешь
public string Api {get; set; }
//настройка которую будешь парсить чтобы рассчитать время запуска
public string Settings { get; set; }
//время последнего фактического запуска
public DateTimeOffset LastStart { get; set; }
//время следующего рассчетного запуска
public DateTimeOffset NextStart { get; set; }
//чтобы можно было отследить че там умерло в процессе и перезапустить если надо
public JobStatus Status { get; set; }
}
Если ты про си/плюсы, то я на них и так работаю, лул.
Просто такое дело, что по долгу службы - я вынужден не только на си писать. Их - чтобы под устройства писать ВПО, чтобы писать всякие конфигураторы устройств, серверы по сбору данных и прочее - надо таки чет более высокоуровневое.
А еще я фронтенд на ангуляре пишу.
Да. Такие вот дела. Да.
Зачем некоторые тащат помойный grpc в ненагруженные сервисы, куда прилетает максимум 5-10 запросов в минуту?
Ладно бы еще тулинг и прочая обвязка в виде мониторинга и прочих хуиток была норм. Но там все через жопу и банальное логирование делается через три пизды. Всякие моки-тесты - хуй напишешь. Нахуя страдать, шарпаны?
Так на раннем этапе - ты ж не знаешь, че там будет нагружено, че нет.
Плюс - делать зоопарк из технологий тоже не хочется: Тут мы рестом, тут grpc, а тута - вообще свой протокол придумаем, чтобы охуеть как круто было.
Плюс, бананльно, это может быть прописано в требованиях к сервису - потому пиши.
>Так на раннем этапе - ты ж не знаешь, че там будет нагружено, че нет.
Про преждевременную оптимизацию что-нибудь слышал? Зачем себе усложнять жизнь, если тебе неизвестно, что сервис в принципе будет нагруженным? И да, сервис уже давно в эксплуатации - 3 года. Количество запросов не выросло.
Тебе нужно такое событие, которое будет генерироваться при нажатии каждой кнопки?
Нет, только когда произошёл ввод в ячейку существующей строки.
Как определить, что ввод закончился, если клик по другой ячейке тебе не нравится?
И ты предлагаешь на каждый инпут - дергать событие?
Просто обычно - в датагриде - при изменении значения - сразу сохраняют в базу/отправляют какому-нибудь контроллеру, который в базу сохраняет/вью модельке отправляют, которая отдает модельке, которая в базу сохраняет. Ебатория будет та еще.
Но вообще, тебе никто не мешает свое событие намутить как ты хочешь.
Ох ебать. Может есть какой-то redraw? Должна быть какая-то функция принудительного обновления UI. Именно поэтому нежелательно использовать контролы в качестве хранилища данных — они медленно обновляются или не успевают обновиться.
Месседжбокс не стоит юзать, он запускается с задержкой, он перерисовывает интерфейс или меняет фокус окна, короч с ним часто все работает. Попробуй Debug.WriteLine("Сообщение") предварительно открыв Окно Интерпретации в Visual Studio.
В WPF, если юзать MVVM, то у текстбоксов и вероятно итемов есть так называемый параметр UpdateSourceTrigger.
К примеру флаг UpdateSourceTrigger=PropertyChanged заставляет обновлять свойство при каждом изменении, а UpdateSourceTrigger=LostFocus обновляется только при потере фокуса (он по-умолчанию).
А еще нах ты Delete срешь в каждой строке? Разве она не должна быть рядом с кнопкой "Обновить"?
Ты в курсе, что из-за лени написал в 50 раз больше строк?
У меня, оказывается, приобновлении данных в БД не отрабатывает sqlDataAdapter. Только при добавлении и удалении строк работает. Я ХЗ, что делать даже. Сижу ищу решение, и всё как-то не то.
Даже если не заморачиваться с автогенерацией столбцов, то в втф понадобится ровно 7 строк для привязки каждого столбца (если не юзать хитровыебанные стили). И ты можешь настроить поведение обновления: хош при каждом вводе символа, хош при переключении на другую ячейку. Там даже кнопка "Обновить" не понадобится.
Пчел ... в финформсах ровно тоже самое. Она строчка, чел. Одна строчка.
https://metanit.com/sharp/adonet/3.1.php
А вот еще в датасете нужно обязательно применить изменения
Я бы тебе помог, но не буду принципиально, пока ты не перепишешь нормально.
The connection pool has been exhausted, either raise MaxPoolSize (currently 100)
Типа блин. Я понимаю, что можно просто увеличить размер пула, но это же не решение проблемы.
Я, в свое время - делал жуткий велосипед с очередью на выполнение вот такой вот хуйни. Но мне не хочется тащить этот велосипед и в другие проекты. Тем более, что такой вот велосипед влечет за собой понижение скорости работы.
А как быть - хз.
Ну и да. Проблема не только при большой нагрузке встречается, но и при оч долгой работе сервера, допустим, без велосипеда с очередью - через полгода аптайма - оно просто упало нахуй.
Просто при большой нагрузке - оно быстро вылетает.
Ну. Т.е. в чем проблема собственно.
При ебейшей нагрузке - npgsql - создает кучу коннектов.
Но природа EF и npgsql такова, что контексты БД - создают эти коннекты на свой поток. И потом, как нагрузка спала - используется один-два реальных коннекта, остальные - просто висят, но может случиться страшное - и родится новый тред, который попробует новое соединение открыть, и вот тогда - сразу пизда.
Как я решил в свое время. Я, как уже сказал, сделал велосипед с очередью обработки запросов, там - 10-20 воркре-тредов - очередь обрабатывали, брали из очереди, создавали контекст. Все норм работало. Но это было жутко неудобно, да и со стороны смотрится уебищно что пиздец. Оно работало правда.
Другое решение - не пулить коннекты, тогда после отработки запроса - реальный коннект - закрывается, но это сразу пизда производительности.
В тырнетах - я чет единственное предложение что вижу - ставить приблуду посредине между приложением и БД, которая будет оборачивать кучу контексто в один коннект и уже через него работать. Но быстрый гуглеж говорит, что приблуда платная, а я на это идти не хочу в данный момент.
Допустим элемент страницы биндится к дата контексту этой страницы.
И вот я меняю страницу на новую и я не хочу, чтобы старая продолжала обновляться. Я беру и присваиваю null в DataContext. Что там под капотом? Автоматом как-то происходит анбиндинг или что?
Студия просто говорит что код - говно, ставит 50 баллов в индексе удобства поддержки. Портит всю статистику.
А как иначе - хз.
Ты поехавший сектант.
>int func() {
>}
Смотрится логично, т.к. начало не у пустой строки.
Зато я первым скажу, что ты душнила.
Как известно, душнила тот, кого первым назовут душнилой
- нет модификатора доступа
- не возвращай void
- m, u - здесь тебе не C, за такое пиздят.
- user.Login - Если user это поле класса, то либо this.user, либо, что лучше - _user
- блок связанный с city - вынести в отдельный сервис.
- алсо, если метод OnAuthMessage, является не методом сервиса, а методом какой-нибудь модели, то обращаться из него в бд, вообще пиздец.
- respoce - что это? (подозреваю, что должно быть response)
Плюс еще возможно до обработки ошибок доебаться, но хер знает, может она у тебя снаружи прикручена, то х.з.
Проверил эти ваши метрики у себя тоже.
79 баллов это норм? Картину портит Serilog, лол.
Ну вот такие минусы полной кастомизации, которая взамен дает тебе возможность переделать комбобокс как угодно. Ну а если ты не собираешься переделывать стиль целиком, то нах тебе впф?
кастомизация тут не причем. тут РУКОЖОПСТВО разрабов, которые в дефолтный стиль ХАРДКОРЯТ цвета
в итоге получается тупость
в вин 7 ты допустим меняешь цвет выделения с помощью банального задания в ресурсах контрола цвета с нужным кеем
<SolidColorBrush x:Key="{x:Static SystemColors.HighlightBrushKey}" Color="Red" />
а в вин 10 это не работает уже (или же вообще никогда не работало даже в вин 7) и нужно приседать с бубном.
И подключать триггеры (если повезет), а если не повезло, то... ради замены одного цвета нужно перегружать ВЕСЬ шаблон с триггерами и всем этим.
>кастомизация тут не причем. тут РУКОЖОПСТВО разрабов, которые в дефолтный стиль ХАРДКОРЯТ цвета
Это да. Причем иногда даже забывают биндить свойства в шаблоне — ты их меняешь, а изменений нет. Но это касается только сложных контролов, из-за чего у меня даже возникает подозрение, что это сделано умышленно, ибо будет 100500 биндингов к 100500 депенденси проперти, что не способствует производительности.
>И подключать триггеры (если повезет), а если не повезло, то... ради замены одного цвета нужно перегружать ВЕСЬ шаблон с триггерами и всем этим.
Триггером в большинстве случаев ты должен менять только свойства стиля, для этого не нужно переписывать весь шаблон. Однако шаблон должен биндится через TemplateBinding к этим свойствам.
Триггер не должен менять свойство конкретного элемента в контроле, если только он не интегрирован в самом шаблоне.
Ах да, еще все стили для комплексных контролов — это сборная солянка из примитивных контролов, поэтому жесткий биндинг свойств во-первых бессмысленно переопределяет стиль, а во-вторых добавляет тебе лишней работы по контролю всего зоопарка стилей.
В большинстве случаев я меняю стиль TextBlock и мне не надо париться с прописыванием стиля в других элементах, где он встречается. Но это касается для случаев, когда ты меняешь полностью тему, а не какой-то конкретный контрол. По факту у меня словарь со стилями для всех элементов.
в большинстве - не значит всегда
в итоге банальное превращается в портянку
https://stackoverflow.com/questions/16819577/setting-background-color-or-wpf-4-0-listbox-windows-8/16820062
добавить в лог и пробросить исключение. Его поймает тот, кто знает что с ним делать.
Если не знаешь что делать с исключением на каком то уровне - значит ты должен либо не ловить там, либо пробросить дальше. И так поднимаешься пока не попадешь в место где знаешь что с ним делать.
Даже если это на самом верхнем уровне или вообще нигде (fail fast подход)
То есть следуй правилу "я не знаю что делать с исключением - пусть разбираются выше".
Поэтому на этих уровнях catch и не нужен. Исключения
1 ловим, логгируем и кидаем дальше
2 ловим, добавляем Data и кидаем дальше
3 граница контекста - ловим и оборачиваем в новое.
>Проект в соло делаю, поэтому спрашиваю
Он имел ввиду не конкретного чела, а функцию, которая "знает что делать дальше", предполагая что твоя локальная функция не занимается самодеятельностью вроде закрытия приложения или попытками исправить ошибку влезая туда, куда не стоит.
Но есть функции, которые в принципе выдают исключение в качестве одного из ответов, такие исключения никуда не пробрасываются и даже не пишутся в лог. К примеру парсер цвета. Пока пользователь набирает условное значение #bb6c8a, парсер будет выдавать исключение и это не должно засирать лог.
Есть функции, которые принимают дефолтный результат перед тем как начать действовать. Если возникает исключение, то функция выдает это самое дефолтное значение. К примеру чтение настроек. Если по каким-то причинам не найдена нужная настройка, функция возвратит дефолтное значение. Таким образом у тебя всегда будет хоть что-то работающее.
Есть случаи, когда функция обязанна что-то вернуть, но null тоже является валидными данными, к примеру это будет значить пустой текстбокс. Например в конвертерах значений WPF, в случае ошибки возвращают специальное значение, сообщающее, что не надо ничего менять.
>Добавить в лог и...вернуть null
Зависит от того насколько критична ошибка.
Можешь в лог, можешь в UI написать пользователю, что возникла проблема, можешь рамочку подсветить.
Если твоя функция НЕ обрабатывает данные в процессе набора текста, то она вообще не должна обрабатывать исключения. Ибо обработав исключение что она сделает? У тебя моментально возникает этот самый вопрос "а что дальше?". Родительский метод запишет твой null в базу данных или отменит операцию записи? Если отменит, то чому бы ему не ловить эксепшин, раз он принимает решение?
Используй ФП и Result<T>.
Когда распробуешь - подсядешь и уже не сможешь писать так как раньше. И не сможешь быть пидором, пробрасывающим обрабатываемые исключения между слоями.
А где там сохранение данных в БД? По твоей ссылкке я вижу только заолнение таблицы данными из БД.
>>2639299
Не помогает. Что именно я делаю не так? Как новые значения в ячейках существующих строк сохраняться в БД?
да прямо таки
вот я под андроид пишу исключительно в реактивном стиле
но в шарпе это ничуть не приживается - оверхед видно, а пользы не оч.
так что на любителя.
Делай так!
Да. На первом скрине - обосрамс небольшой, но его легко заметить, так что не критично.
>вот я под андроид пишу исключительно в реактивном стиле
>но в шарпе это ничуть не приживается - оверхед видно, а пользы не оч.
Реактивность насколько я знаю в там где UI и десктоп фреймворках вполне себе используется. А вот в бэке она просто нахуй не уперлась, поэтому и не используется. А ФП это про другое.
>Что это?
Функциональное программирование
>Result<T> видел только в тасках.
Глянь вот тут https://github.com/vkhorikov/CSharpFunctionalExtensions
Интересно, было что-то похожее на второй скрин, но я решил отказаться хз почему. Только я возвращал BaseResponse, который состоял из кода ошибки, описания и Data, если она есть
Я вообще логики не пойму. Почему AcceptChanges идет после Update, в моем понимании нужно сперва применить изменения, а потом уже пихать в базу данных. Но NET название не всегда соответствует функционалу, или там такой многоступенчатый смысл, что сходу не допереть.
Я бы порекомендовал для начала повторить пример метанита и понять работает ли.
>Почему нельзя написать просто DataContext = user? Зачем создается свойство User User?
Лично я так делаю потому, что DataContext имеет тип Object и если для биндингов все норм, то для меня это неудобно — хочется видеть данные нужного мне типа. Чисто для внутреннего удобства.
Только я не понял, схуя ли назначение на свойство user идет при инициализации, а не при событии DataContextChanged. Вот щас "условный" пользователь в ходе работы приложения сменит DataContext, а в user останется старый экземпляр и усё, приехали.
Можно ли меняя к примеру свойство R как-то уведомить, что изменился весь RGB? Или только подписка на событие OnPropertyChanged? Просто получается геморный Disposable класс, который нужно высвобождать.
У меня клиент.
Нужно работать с IMAP, получить папки, также скачивать письма и приложения к письмам.
Еще нужно юзать гугл диск апи и яндекс диск апи.
private void dataGridView1_CellValueChanged(object sender, DataGridViewCellEventArgs e)
{
//
...
//
}
А как пометить цветом ячейку, значение которой было изменено? В интернете я нашёл только строчку вроде "dataGridView1.Rows[e.RowIndex].Cells[1].Style.BackColor = Color.Red", но как получить координату ячейки автоматически, как еслибы существовал метод e.CellIndex?
Простите, а нахуя?
Тебе пихается экземпляр этой ячейки через sender. Просто приведи ее к типу ячейки Cell (или что там) и делай с ней что хочешь.
При изменении ячейки, эта ячейка вызывает событие и отправляет себя в качестве сендера (буквально кто отправитель), попутно отправляет необходимые данные в качестве EventArgs (котоырй DataGridViewCellEventArgs).
> как еслибы существовал метод e.CellIndex?
e это EventArgs т.е. аргументы события — некая сопутствующая информация. Там вряд ли должны находиться методы, там могут быть только свойства.
Че бухтишь? Твой любимый Виндоу Формс. Все гнал бочку на WPF, а как дело зашло за формсами, так все утихли.
Затем что создано оно для других причин. Видно же что это не MVVM.
Остальное артефакты записи
Чтобы каждый раз при обращении к вьюмодельке не приводить типы.
Diazepam12#8984 дс для связи
Потенциально до нескольких сотен клиентов одновременно, пакетов много, но их размер исчисляется максимум парой десятков байт
Имею TcpListener, который делает делает accept на входящие коннекты
И вот здесь затык, как мне лучше сделать запуск обработчика клиента, в качестве тасок или выделять каждому клиенту свой тред с обработчиком
ЗЫ
Исходно намеревался стартовать обработчики через Task.Factory.StartNew(handler) с опцией LongRunning
Но перечитал стэковерфлоу(вьебал говна) и теперь сомневаюсь в своей компетенции по данному вопросу
ЗЫЗЫ
Вспомнил что это сорта говна, только в случае с фабрикой тасок разруливать говно и заниматься излишним пердолингом буду не я, и выйдет менее накладно по ресурсам
Сам спросил - сам ответил
<?xml version="1.0" encoding="utf-8"?>
<Objects>
<Object Type="System.Management.Automation.PSCustomObject">
<Property Name="EmailAddress" Type="System.String">[email protected]</Property>
<Property Name="ExpirationDate" Type="System.DateTime">21.07.2022 10:54:59</Property>
</Object>
<Object Type="System.Management.Automation.PSCustomObject">
<Property Name="EmailAddress" Type="System.String">[email protected]</Property>
<Property Name="ExpirationDate" Type="System.DateTime">23.02.2021 5:51:59</Property>
</Object>
</Objects>
Помогите, пожалуйста, вытащить property с атрибутом Name="EmailAddress".
Я смог вытащить первый элемент с Name="EmailAddress", но вот второй не получается. Мои потугуи на картинке.
Пример с msdn https://learn.microsoft.com/ru-ru/dotnet/standard/linq/find-element-specific-attribute
visualsToXpsDocument.BeginBatchWrite();
for (int i = 0; i < paginator.PageCount; i++)
{
visualsToXpsDocument.Write(paginator.GetPage(i).Visual);
}
visualsToXpsDocument.EndBatchWrite();
Просто записываю visual в xps документ и мне на 3 элементе выдаёт null, хотя там 146% не null. Если просто записать так
visualsToXpsDocument.Write(paginator.GetPage(2).Visual);
То всё нормально. Можно хоть 100 объектов записать таким образом и никаких null не будет. Но в цикле, сука, просто null и всё. Если заранее записать visual в коллекцию и потом по индексу к ней обращаться
visualsToXpsDocument.Write(visuals[0]);
То вообще ни одного элемента не записать, в цикле или не цикле - похуй, сразу null, хотя все элементы в коллекции нормальные
Что это за бред ебаный?
Всегда пожалуйста!
А теперь ты должен поставить этот стикер и обоину в свою студию.
Я раза с 10 заметил, где кончаются аргументы конструктора и начинается тело.
Придется обратно вертать(((
>где кончаются аргументы конструктора и начинается тело.
Ну это решается просто, добавь пустую строку между сигнатурой и телом метода... Ой бля, падажди. Это же та же самая хуйня против которой сражаются адепты жабаскобок.
Ну. Видимо да. Придется возвращаться к шарповским скобкам.
Целых 4 дня получается продержался.
Вообще. На самом деле - экономия места - тоже прикольно. Когда не такой пиздец - больше умещается.
Наверное для себя бы то что в теле метода - с сишным расставлением скобок делал, а для методов-конструкторов - отбивал бы явно с новой строки в шарповском стиле.
Но это будет уродливо.
СЛОЖНА.
Вот почему нельзя как сишники - писать сокращениями-то? У них в 100 символов умещается имя, 12 аргументов и вообще.
Аноны, как вы думаете, легче устроиться джуном, если за плечами есть несколько лет фронтенд разработки (typescript)? Или всем похуй?
Если не только кнопки красил, можешь даже миддлом устроиться при желании.
Ну на react и vue кнопки обычно не красят.
>можешь даже миддлом устроиться при желании
Слабо себе представляю, как человек из другой области (хоть и знакомый с программированием) может сразу устроиться мидлом. В продакшене я много раз встречался с ситуациями, когда даже при наличии теоретических знаний можно погореть из-за отсутствия практического опыта.
Но за поддержку спасибо!
Я, как дед, все еще считаю, что программирование - это про способы мышления.
Ну так вот. Мидл отличается от джуна, в плане мышления, что у него - внезапно должна была начать закрадываться мысль, что код, сам по себе - нихуя не стоит и не нужен, ваш код - способ удовлетворить потребность клиента и все вот это вот.
Ну так вот. А дальше, как дед продолжаю. Все языки +- похожи. Я начинал в школе с паскаля, в вузе - плюсы, на работе джава-шарп-питон. Фундаментальные различия - не то чтобы присутствуют, Ну, т.е. да, можно сказать, что вот там ты можешь работать с памятью напрямую, тут у тебя сборщик мусора, там ты в песочнице вообще возишься. Но вцелом, если ты в состоянии самостоятельно написать что-то уровня ПХП, ну или там свой интерпритатор команд, компилятор, приложение с системой плагинов; то опять же, фундаментально - отличаться один язык от другого - не будет.
К чему я. К тому что все зависит от того на какой ты стадии развития.
Про развитие - легче будет. Какие-то же знания про то как гоняются твои запросики до сервера уже должен был получить, представлять что такое БД, уметь простенькие SQL-запросы писать и вот это вот все. Ну. Т.е. знания некоторые есть, теперь - смотришь с другой стороны и должно быть полегче. Как с изучением других языков: знаешь английский, француский будет выучить легче, немецкий - еще легче; японский - будет так же легче учить, чем если бы ты его первым после родного решил осваивать.
А про найм. Ненулевая вероятность, что для ХРа - твой опыт - не опыт, так что придется по общим правилам, т.е. на рандоме.
А теперь время хуевых аналогий.
Переучиваться с одного стека на другой - это примерно как умея играть на праворукой гитаре, переучиться на леворукую.
В теории это выглядит не сложно, но пипец как геморно на практике. И в некоторых аспектах сложнее чем если учиться сразу на леворукую гитару.
Да, тебе не нужно заново изучать теорию музыки и основы игры на гитаре в этом аспекте проще. Но тебе не просто приходится нарабатывать новые моторные навыки с нуля, а сначала ломать очень прочно закрепленные старые. И для многих это может стать более тяжелым, чем освоение с нуля.
Мой поинт в том, что люди разные и для некоторых перейти в новую парадигму может и не быть проблемой, но для некоторых (и не факт что их меньше), это может быть сложным процессом требующих специфических усилий (а не просто 'выучить новый стек'). Т.к. фундаментально хе-хе программирование - это такой же навык, как и игра на гитаре или езда на велосипеде (попробуй научись ездить на веле у которого руль в обратную сторону от колес вращается). И он где-то наполовину состоит из понимания, а на вторую из обычного задрачивания свое нейросети.
Дед правильно говорит
Как только понимаешь очередную концепцию, то язык уже не имеет значения.
Потому первый яхык учить сложно, а второй+ зависит от твоего понимания концепций.
Я уточню.
Допустим у меня есть библиотека А
В нее добавлена библиотека Б
А теперь мне нужно библиотеку А поместить в решение, в котром УЖЕ есть библиотека Б. И тут происходит конфликт неймспейсов.
У меня раньше такой хуйни не было с библиотеками. У меня dll как копировалась в сборку и кому нужно — тот брал. Я мог в любой проект импортировать библиотеку без каких либо конфликтов с соседними.
>И тут происходит конфликт неймспейсов.
шта? какой еще конфликт.
Что-то типа неоднозначность имен. Студия похрустела и чет восстановилось.
Плохая аналогия. Интеллект не моторика, понимать можно хоть сколько парадигм, они друг другу не мешают, а моторика мешает. Если же у человека только одна парадигма в башке помещается как моторика, перед вами скудоум, просто даун.
По итогу хотелось бы иметь общий неймспейс, как если бы это был один проект.
А чем обычные либы не дают нужного? никто не запрещает создать MyLibExt, добавить туда MyLib и заюзать тот же неймспейс.
также есть понятие shared project в студии, хотя лично мне сложно придумать где бы не хватило либ (ну кроме проблем области видимости, но зачем себе их создавать)
Я понял, но для этого классы должны иметь хотя бы неймспейс второго уровня. У меня щас все в корневом неймспейсе, но это уже мои проблемы.
>но для этого классы должны иметь хотя бы неймспейс второго уровня
????
Первое что сейчас. Второе, что мне было надо и что кажется было бы правильнее.
>Чем больше я ебусь с этой тем больше ловлю себя на мысли, что объективно достаточно было вот такой структуры
Ты себе даже не представляешь на сколько. На проде один раз только писал тсп-сервак, для одной железяки.
Нуууу. Если так рассуждать - ниче не надо делать же.
Просто все эти моменты.
Вот я делал-делал. Пришло понимание, что есть всякие FTP, где на сервере одновременно по UDP и по TCP и надо как-то это тоже учитывать и все такое. А сделать все эти диспечеризации сообщений и прочее - нах не упало, если у тебя протокол хорошо описан и там никаких особых вещей быть не может.
А SNMP - ну, пиздец, я заебусь с этой ASN.1 и мибами. Не люблю SNMP, но только для них и кажется было бы полезно. Правда там нужно было бы с UDP начинать.
> что есть всякие FTP, где на сервере одновременно по UDP и по TCP и надо как-то это тоже учитывать и все такое
на самом деле не надо.
FTP работает как комбинация контрольного соединения TCP и нескольких TCP-соединений с данными.
Хуй знает что тут у вас происходит, просто зашел поправить.
А SNMP, конечно, пиздец.
> на самом деле не надо.
> FTP работает как комбинация контрольного соединения TCP и нескольких TCP-соединений с данными.
Точно? Я почему-то в голове помню, что там слушается порт UDP который ловит от сесии команды всякие. Может быть я еблан и себе это сам придумал.
Видимо ты прав. Погуглил.
Дырявая башка. Последнее время стал замечать что путать стал чаще. Надо наверное нормализовать режим сна и хотя бы 6 часов спать.
>понимать можно хоть сколько парадигм
Понимать, не значит уметь применять. То же ООП очень простая концепция с всего несколькими ключевыми принципами. Но дохуя программистов которые не умеют его нормально применять, при том что они могут быть гуру в каком-нибудь лоу-левел кодинге или функциональщине.
И что? Это не относится к сказанному. Человек лучше делает то, что он делает больше, это обычный навык.
Если собрано в сингл файл бинарник - не вскроешь на отладку
Бля, как будто с тупой нейросеткой общаешься, которая теряет контекст через пару сообщений.
>.Net Core без исходников, независимо от ОС?
посмотри dnSpy
жаль он умер но только что попробовал - отлаживает нет кор 3.1 и 6 точно.
Вот ресурс
<Grid.Resources>
<p:ProbeInfo x:Key="uProbe" x:Name="ProbeName" />
</Grid.Resources>
Вот кнопка, пытающаяся привязаться к свойству "IsEnabled"
<ToggleButton IsChecked="{Binding IsEnabled,
RelativeSource={RelativeSource AncestorType={x:Type p:ProbeInfo}}}" />
Вот ошибка
System.Windows.Data Error: 4 : Cannot find source for binding with reference 'RelativeSource FindAncestor, AncestorType='ColorPicker.Probe.ProbeInfo', AncestorLevel='1''. BindingExpression:Path=IsEnabled; DataItem=null; target element is 'ToggleButton' (Name=''); target property is 'IsChecked' (type 'Nullable`1')
Пытался привязаться и через ElementName - без толку. Я типа должен юзать StaticResource, но хз как.
вернее Source={StaticResource uProbe}}"
ибо поиск идет по x:Key, но это ты уже и сам понял
У меня база загружается за 500 миллисекунд, это не дохуя ли? Там всего 4 строки и 4 столбца.
Xml файл на 100 записей, в каждой по 14 свойств грузится в 10 раз быстрее. Вот и думаю, мб я что-то не то делаю.
Ты куда то спешишь?
На деле твой вопрос не имеет смысла без описания как загружаешь
Например орм потратит время на создание маппинга при первом запросе (хотя зависит от орм)
Короче, есть цикл в который я передаю канселейшн токен, в нем есть ожидание Task.Delay(n). Проблема в том, что ожидание может быть достаточно долгим, прежде чем начнется новая итерация цикла и проверка токена отмены. Я решил "а почему бы этот токен так же не предать в Delay, чтобы не было бесполезного ожидания" но получаю вышеуказанное исключение.
А еще обернул в Try Catch, а исключение продолжает срать в окно интерпретации.
>Никаких файлов в папке создано не было. Что делать?
Оказалось, антивирус блокировал файл powershell, убрал из карантина и все заработало
> но получаю вышеуказанное исключение.
ууу, ыыы, призываю духов, взываю к предкам....
не, чет не выходит угадать что за код у тебя там.
(кстати если там HttpClient то все понятно)
>срать в окно интерпретации
если это output то почему бы и нет
> TaskCanceledException
Это такой вот охуенноый костылище, который придумали майки, чтобы отменять задачи.
Да. Да. Не удивляйся. Это именно то, как они предлагают отменять асинхронные операции - исключением. Еще вариант - OperationCanceledException, но это для потоков.
Такие вот дизайнеры у нашего языка.
Возникает оно у тебя, потому что токен который ты передал - в состоянии Cancelled.
Вообще. Типа я понимаю в чем смысл этого дизайнерского решения. Но пиздец оно раздражает на самом деле. Потому что весь, блядь TPL - придуман чтобы быть быстрым. Ну дак вот. У тебя 10к сокетов, таск на чтение, таск на отправку. Сеть отрубилась. Со старой моделью, ты нормально отрабатываешь это и вообще не замечаешь. С новой - у тебя посыпались эксепшны, проц в 100% улетел, пока это все отловится, пока отработает, пизда полная. И ты страдаешь, ждешь 10к отключений пока отработают, сеть уже появилась, новые клиенты ломятся, а ты все обрабатываешь те исключения. Срака полная.
1 исключение - штатный механизм прерывания работы "дальше работать нельзя ". Альтернатива - прокидывать ошибку по всем уровням явно.
2 OperationCanceledException ни для каких потоков. Это просто более общее исключение отмены. И базовый класс дляTaskCanceledException
3 TPL придуман чтобы дать унифицированный подход к асинхронщине с не хрень вида new Thread или BeginXXX
> 1 исключение - штатный механизм прерывания работы "дальше работать нельзя ". Альтернатива - прокидывать ошибку по всем уровням явно
Альтернатива - вернуть статус - операция была прервана и кидать ошибку уже при попытке достать результат задачи.
Блин. Вот почему-то при попытке читать из пайпы - они возвращают ReadResult у которого - можно посмотреть IsCancelled и IsComplete, вместо того чтобы страдать хуйней, а отменить задачу чтения можно по человечески без кидания исключений.
А кидать исключение если у тебя отменяют любую асинхронную задачу - бредово. Сами майки, когда им надо - это понимают и исключений не кидают, а придумывают обходные механизмы со всякими статусами. Но наружу тащат апи, которое постоянно кидает исключение по поводу и без.
> OperationCanceledException ни для каких потоков
> The exception that is thrown in a thread upon cancellation of an operation that the thread was executing
Конечно, можно считать, что оно к потокам никакого отношения не имеет, но если мы берем эту хреновину в контексте однопоточного приложения - оно вообще смысла не имеет, потому что мы можем нормально отработать отмену корутины через флаг, не страдая всей этой хренью с исключениями.
Ну и в контексте однопотока - оно вообще никогда не бросится, потому что некому отменять
https://sd.blackball.lv/books/17528
>что оно к потокам никакого отношения не имеет
нет не имеет.
твоя цитата говорит про отмену выполняемой операции, а тред упомянут просто так (чтобы было понятно что такое эта ваша операция)
это исключение всего лишь говорит что "то, что вы делали/ожидали/надеялись/верили, было кем то отменено. Вы об этом знайте там наверху. И может быть вот вам даже токен отмены для ясности".
Кооперативный паттерн отмены не имеет никакого отношения к потокам.
>А кидать исключение если у тебя отменяют любую асинхронную задачу - бредово
исключения - базовый механизм.
Твои претензии ясны, но тогда были бы вопросы - а хули базовые вещи имеют свой дизайн? что за бардак в языке.
Но так уж повелось что были выбраны исключения как средство управления потоком выполнения при ошибке.
шарп слизывали с жавы, а думали уже потом, когда было поздно. Ну или не думали. До сих пор удивляешься что базовые вещи либо нет вообще, либо интернал, либо убого.
>в моем случае это шифрование
Не советую заниматься автоматизированной обработкой в этом случае. Там очень вероятно много где использеутся ансейф для доступа к криптопровайдеру. Поэтому убрав какое-нибудь вроде бы ненужное поле в итоге можно получить пиздец. Причем узнать о нем уже на стадии когда это будет глубоко в проде.
Только руками, только хардкор.
>>2646907
>а именно перенос в namespace проги
Проще убедить начальство, что это тупая идея и в виде отдельной библиотеки это намного проще будет мэйнтейнить.
>срать в окно интерпретации
>если это output то почему бы и нет
Потому что это сбивает с толку визуальным шумом. Я знаю, что будет эксепшн и я его оборачиваю в Try Catch. А теперь представь, что этих эксепшинов штук 50, а в другом месте еще 100. Я заебусь это говно разгребать.
>>2645812
Отказался я от этой затеи — пихать токен в делэй. Пока не критично.
делаю цикл
for(.....)
{
int var = 1;
......
}
Как я понимаю каждый раз в начале цикла создается переменная. Что с ней происходит когда цикл заканчивается? Он типа засирает ячейки памяти каждый раз создавая переменную в новой ячейке или он по окончанию цикла удаляет ее и потом в начале следующего создает заново? Лучше ли снаружи цикла объявить переменную и инициализировать ее или похую? Снаружи цикла я ее не использую.
Я нюфаг тапками не бейте.
Точнее не присваивать ей значение снаружи цикла а просто объявить, мне надо чтоб значение обнулялось (объединялось лол) каждое начало цикла.
Простейшие типы данных, типа структур для того и созданы, чтобы ими срать внутри цикла.
Имеет смысл создавать переменную до начала цикла только в двух случаях:
1. ты хочешь, чтобы значение переменной сохранилось на выходе и как-то потом дальше его юзать.
2. твоя переменная - класс. И чем сложнее класс, тем хуже подходит для многочисленного и частого создания экземпляра. Классы не удаляются мгновенно, а ждут сборщика мусора, поэтому таки да в этмо случае может накопиться говно. А если класс простенький, да к тому же часто используется в циклах, то имеет смысл превратить его в структуру.
Еще раз. Класс — долгоиграющий объект, часто сложный объект, который ты создаешь ДО цикла и дальше в цикле редактируешь. Структура — простой объект, который "быстро создал, быстро забыл". Структура идеально подходит, чтобы создавать новый экземпляр при каждой итерации цикла. Там настолько все быстро, что нет смысла оптимизировать , если только твоя структура не string, но это уже другая история.
>>2647197
>Я нюфаг
Ага.
Хуй забей, компилятор сам все оптимизирует. Вплоть до того, что если будет нужно, то сам вынесет (или внесет) переменную куда нужно.
>Что с ней происходит когда цикл заканчивается?
Она уничтожается.
>или он по окончанию цикла удаляет ее и потом в начале следующего создает заново?
Видимо ты "конец цикла" путаешь с "концом итерации". Так да, если ты объявил переменную внутри тела цикла, то каждую итерацию будет создаваться новый экземпляр, но бессмысленно пытаться в оптимизацию. - либо ничего не выйдет, либо ничего не выйдет.
Ты посмотри сколько весит переменная bool (думаешь 1 байт? а на самом деле 4 байта), и задумайся, а этот язык вообще приспособлен для такой мелочи, которая тебя волнует? Пока ты юзаешь в цикле структуру, шпи шпокойно.
На уровне msil твой код будет переписан под выполнение IL инструкций на основе стека + goto переходов
то есть в начале метода будут выделены ячейки
(кстати где? это я так и не понял)
под локальные переменные и им присвоено дефолтное значение.
а далее из этих ячеек будет писать в стек, выполнять операции, извлекать из стека.
и твой int var = 1; превратится в
1)кладем на стек 1
2) извлекаем из стека 1 в ячейку для переменной var
то есть ничего нового в итерации не создается. да и нет никаких итераций в MSIL - там просто гото. В стеке ничего не задерживается - операции для своих нужд извлекают значения из стека тем самым опустошая его. Потому нет миллиона итераций - есть миллион (push/pop стек) и затем goto.
Как оно?
Просто я попробовал на реальном проекте поиграться, оно при старте начало грязно выраджаться про то что не может чет там найти конструктор к DbContext'у, ну я и забил. Но все равно интересно же.
В интерпретируемой скриптопараше как С# ответа на этот вопрос нет, он скрыт внутри машины интерпретатора и не афишируется, и тем более может в любой момент поменяться по велению левой пятки разработчиков. Поэтому в таких говноскриптах нет документации по их внутренней работе, если тебе надо что-то получить, ты должен ради этого ставить эксперимент созданием тестового кода измеряющего нужные тебе параметры и смотреть на результат, при условии что это вообще возможно, что не гарантируется тоже.
>В интерпретируемой скриптопараше
>С#
Джавадебил совсем уже обезумел, охуеть. Пора мочу вызывать.
Решение для работяг оно же дефолтное - json. Просто делаешь себе класс настроек (или несколько вложенных классов), а дальше сериализуешь и десериализуешь. На все потребуется System.Text.Json и пара строчек.
ЖДАНОВ так старательно всё замазывал, но всеравно спалил, что он ЖДАНОВ
Гражданин Жданов М. у вас пиратская копия Visual Studio полиция уже выехала по вашему адресу.
>>2647743
Специально не написал первым, что обосрался. Думал, что не заметят,но нет, тут всё как обычно
столько сколько нужно же, но не больше необходимого
главное чтобы это имело смысл.
Также не стоит забывать про приемы оптимизации выполнения выключенного лога. Ну чтобы или вообще в релиз сборке не было лишних вызовов или же ветка логгера не выполнялась. В примитиве это logger.IsDebugEnabled и тому подобное.
>logger.IsDebugEnabled
Я сам чекал и просто повышал ограничитель уровня до Information для релизной версии, а если программа завершалась некорректно, то уровень понижал до Verbose. Для дебаг сборки тоже свое условие.
Еще напрягает куча стринговых сообщений, которые нужно хранить прямо в методах.
Я познакомился с Newtonsoft JSON. Во-первых файл конфига получается более читабельным, во-вторых сериализация большинства типов данных работает из коробки, без создания конвертеров (кроме парочки, типа десериализации интерфейсов).
Ну такой чек нужно делать на каждый вызов логгера что не очень удобно и нужно использовать костыли
В остальном ничего не поделаешь - лог есть лог. Если он нужен то придется в него писать.
>>2647899
Жсона из коробки более чем достаточно. Ньютонсофт - лишняя зависимость
>Ну такой чек нужно делать на каждый вызов логгера
Да нет. Только на старте приложения перед билдом логгера.
Устанавливаешь минимальный уровень и все что ниже, не будет записываться в лог.
К тому же есть LoggingLevelSwitch, который по идее может менять ограничение в рантайме, но мне достаточно на старте.
>В остальном ничего не поделаешь - лог есть лог. Если он нужен то придется в него писать.
Так в том-то и беда, не ясно что понадобится. Если пытаться предсказать все случаи жизни, то придется писать всё. Тут по идее всю работу должны выполнять тесты, а логирование нужно только для приблизительного указания ошибки.
>и все что ниже, не будет записываться в лог.
но по прежнему будет вызывать бесполезные аллокации и боксинг на каждой строчке вызова записи в лог )
Ну разве что у тебя шарп 10 и зерологгер то тогда будет некоторая экономия.
>не ясно что понадобится
ну так представь что у тебя фейл и ты читаешь лог. и чтобы ты в нем хотел видеть, а что нет.
тесты не заменяют логи. тесты, диагностика, логи - все делают разные вещи.
>но по прежнему будет вызывать бесполезные аллокации и боксинг на каждой строчке вызова записи
А как иначе? Я тоже задумывался этим вопросом.
Ну создастся кусок стринга в примере ниже, но как я понимаю, метод проверит допустимый уровень логгирования и тупо выйдет на старте.
logger.LogDebug("The message: {v}", value);
А что даст logger.IsDebugEnabled? Он же не удалит строку кода. Кстати я не нашел данной функции для Serilog. Это что-то для NLog? Это можно считать аналогом IsEnabled? Т.е. это тупо проверка уровня до запуска метода.
if (logger.IsEnabled(LogLevel.Debug))
{
logger.LogDebug("The message: {v}", value);
}
Какая разница? Все равно будет выделена память под "The message: {v}".
>logger.LogDebug("The message: {v}", value);
посмотри на сигнатуру метода LogDebug. у тебя произойдет передача value (и боксинг при необходимости) даже если этот лог никому не нужен.
>будет выделена память под "The message: {v}".
не будет. это интернированная строка. то есть она уже занимает память в таблице интернированных строк.
в общем чтобы избежать накладных расходов нужно проверять
if(logger.IsDebugEnabled) logger.LogDebug("The message: {v}", value);
тогда LogDebug не будет вызван и не будет лишних аллокаций
или же использовать шарп 10 и логгер поддерживающий новые форматаблечетотам.
или же засахарить костыли чтобы было вида
logger.Debug()?.Log(...)
>или же засахарить костыли чтобы было вида
logger.Debug()?.Log(...)
Это что-то кастомное? Я просто с бейсика. Допустим Debug это расширение, но оно вернет bool, а как из этого перейти к Log?
Насколько задрочено тебе нужно - настолько и делай
У нас каждый пердеж и выше летит в NLog
>Допустим Debug это расширение, но оно вернет bool
это лисапединг
Debug() вернет логгер если IsDebugEnabled или null, если нет
и если он вернул null, то выполнения ж дальше не будет.
> но по прежнему будет вызывать бесполезные аллокации и боксинг на каждой строчке вызова записи в лог )
Вообще похуй, дрочат на микрооптимизации либо девелоперы ультрасерьёзного коммерческого софта, либо долбоебы собеседующие на галеру.
Этот жабагадюкинг не стоит переживаний и траты внимания.
ага ага. вот из за таких софт и стал тяжелым и тормозным
потому что есть какой нибудь
logger.Trace(..., тут что то тяжелое вычисляется)
а ему пох, ведь "все равно в лог записано не будет, а то что будет тормозить - так наш софт никому и не нужен вот"
А, ну и ещё в туториале челу приходится дописывать Console.ReadLine(); чтоб терминал не закрывался, а у меня и так не закрывается
Неужели тутор за 2019 год уже устарел??????????? Где мне учиться тогда(
Пилишь класс MyAppSettings с пропертями
Пилишь SettingsManager
Затем конструкция уровня
var manager = new SettingsManager();
if(!manager.LoadIfExists<MyAppSettings>(out settings)
{
settings = new MyAppSettings()
{
//инит дефолтных настроек
}
manager.Save<MyAppSettings>(settings)
}
В самом SettingsManager придумываешь где будешь хранить свои конфиги и какие пути будут юзать чтение и запись
В SettingsManager.LoadIfExists чтение и дженерик десериализация с JsonSerializer, с возвратом bool на успешность существования и загрузки конфига и out настроек
В SettingaManager.Save дженерик сериализация и запись в файл
Юзаешь в любом своём проекте, по надобности наследуясь от MyAppSettings и расширяя конфиг.
> ага ага. вот из за таких софт и стал тяжелым и тормозным
> потому что есть какой нибудь
> logger.Trace(..., тут что то тяжелое вычисляется)
Достаточно не быть долбоебом и не прокидывать тяжёлое и вычисляемое в логгер.
Нахуя что-то вычислять дополнительно?
Все что тебе нужно вывести или уже просчитано, либо уже пора выводить стэктрейс.
Можно как юнитидебилы в каждом Update геодату игры полностью пересчитывать
>logger.Trace(..., тут что то тяжелое вычисляется)
А если у меня просто
>logger.LogDebug("The message");
... то проверка не имеет смысла?
достаточно просто не писать в лог когда не нужно и вообще вызывать логгер, когда не нужно
а не строить из себя знатока "таак, тут не тяжелое, так тут пох на боксинг, а тут вообще пох"
>>2648173
тут да - не имеет.
но обычно есть какие то данные
>А, ну и ещё в туториале челу приходится дописывать Console.ReadLine(); чтоб терминал не закрывался, а у меня и так не закрывается
У меня закрывался. Мб у тея еще что мешает закрытию?
> достаточно просто не писать в лог когда не нужно и вообще вызывать логгер, когда не нужно
Ну так убери лишние вызовы, нахуй код говном с If засирать
>To automatically close the console when debugging stops, enable Tools->Options->Debugging->Automatically close the console when debugging stops.
Вот такая штука есть, оказывается.
да.вообще убрать логгирование
и нанять оракула - пусть он разбирается что где произошло.
Ты, видимо, просто тупой
Хотя чего ждать от человека, который в пример приводит
> потому что есть какой нибудь
> logger.Trace(..., тут что то тяжелое вычисляется)
этот пример приведен в доке от джетбраинс (пик)
и для "мудрого" поясню - как раз тупо вообще задумываться на тем какой будет оверхед, умно не допускать оверхеда вовсе.
>Неужели тутор за 2019 год уже устарел?
А ты как думал? Да даже за 2021-й год уже устарел. У нас в шарпе принцип: "Маши крыльями или сдохнешь". Так что ищи только самый свежачок, который только на нглийском, лол.
Ангельский не проблема. Я решил начать через видеокурс C# Fundamentals for Absolute Beginners от Microsoft + параллельно почитываю "Pro C# with .NET 6". Видеокурс от 2019 года, да. Но для базы должно пойти?
Первое, нахуй newtonsoft.json
Второе, если возможно, пили пустой конструктор в классе который пихаешь в сериализатор
Третье, лучше код показывай
Если не можешь менять базовый класс можешь либо ебаться с конвертером, либо накормить сериализатор параметрами
TypeNameHandling = TypeNameHandling.None,
NullValueHandling = NullValueHandling.Include,
MissingMemberHandling = MissingMemberHandling.Ignore,
ConstructorHandling = ConstructorHandling.AllowNonPublicDefaultConstructor,
ObjectCreationHandling = ObjectCreationHandling.Replace,
Вытаскиваю json (пик 1). Класс, который пихаю в сереализатор (пик 2), пустой конструктор есть. 3 пик - json файл. При дебаге всё нормально работает, а при публикации вылезает эта ошибка.
>пик 1
Вот тебе реализация десериализации через newtonsoft, раз уж ты юзаешь его, насколько сходу смог вспомнить, без TObject
private T Deserialize<T>(string text) where T: AppSettings
{
using (var reader = new StringReader(data))
{
using (var jsonReader = new JsonTextReader(reader))
{
return (T)serializer.Deserialize(jsonReader, typeof(T));
}
}
}
>пик 2
навесь аттрибут [JsonConstructor] на конструктор
>пик 3
Твоя модель настроек не совпадает с json
Пили базовый класс AppSettings с конструктором и пунктом 2
от него наследуй SmtpSettings:AppSettings
от него наследуй LetterSettings:AppSettings
>пик 1
Убери из имени метода настройки, у тебя дженерик в итоге получится.
Сделай его синхронным чтобы был out(зачем тебе на ините синхронщина)
//Юзаем так:
var settingsService = new AppSettingsService();
SmtpSettings smptSettings;
LetterSettings letterSettings;
//Грузим конфиги
if(!settingsService.LoadIfExists<SmtpSettings>(smptConfigPath, out smptSettings)){
//создать новый конфиг и сохранить, если обосрались на чтении
}
if(!settingsService.LoadIfExists<LetterSettings >(smptConfigPath, out letterSettings)){
//создать новый конфиг и сохранить, если обосрались на чтении
}
//получаем данные с конфига
var host = smptSettings.Host;
var header = letterSettings.Header;
Я обосрался в десериализации, там new StringReader(text))
Принцип такой короче
>Твоя модель настроек не совпадает с json
Так я беру только "SmtpSettings", "Letter" - это для другого класса. Или это плохо и лучше разделить на разные json'ы?
Или тут про другое? Кароч я уже не соображаю, что тут происходит
Я бы разделил
Если хочешь хранить все в одном месте то делай соответствующую модель, например
AppSettings
{
public SMTPSettings SmtpSettings{get;set;}
public LetterSettings LetterSettings{get;set;}
}
В любом случаее спасибо, завтра переделаю как Вы показали, надеюсь заработает. А пока навесил [JsonConstructor], но всё равно так же ошибка вылезает.
Блять блин, а чё эта ошибка-то вылезает, вроде конструктор пустой есть, [JsonConstructor] навесил, что ещё ему надо
Так, что за модель? Это xml, который я прикрепил или что?
Модель в данном случае это класс настроек с публичными пропертями, содержащими настройки
Я newtonsoft не особо пользую
Попробуй ему кормить чисто json для smtp
А чем тогда newtonsoft лучше заменить, я просто первый раз с json в c# работаю и не в курсе, что в моде, а что лучше обходить стороной
и где тут ньютонсофт
на словах ты ньютонсофт
а аттрибут используешь из System.Text.Json что совсем другая либа
>>2648836
System.Text.Json хватит за глаза раз он у тебя есть.
Мигрируй на System.Text.Json, по умолчанию интегрирован с проектами core3. 0
Вызовы простые
JsonSerializer.Deserialize<Type>(jsonString);
JsonSerializer.Serialize(object)
Как уже сказал, полюбому отказывайся от JObject
один фиг при публикации выдаёт ошибку
Да проблема в том, что при дебаге всё ок, а вот когда нажимаю опубликовать вот это происходит. Мб просто вытащить из релиза bin и себе мозг не ебать
Короче, ванговать сложно, но ошибка, скорее всего, максимально тупая и мы все вместе посмеёмся
Переходи на System.Text.Json, перепиливай на подгрузку файлов и сериализацию/десериализацию через сериализатор
Можешь оставить какой-нибудь канал для связи, будем говнокодить напару
Да, перепилю ибо у меня код сам по себе говно-гавна, мне уже тут посоветовали как сделать лучше. Если есть желание то вот телега: @calciigluconas
Попробуй вообще убери конструктор из класса. По идее для poco классов, он просто дефолтный юзает и все.
Написано же деление на ноль. Что за пидарские вопросики?
>Переходи на System.Text.Json
В этой залупе практически ничего нет. Придется на каждый пук писать конвертер.
>>2648852
А что не так?
>>2648849
Он так ругается, когда нет дефолтного конструктора без параметров. Он у тебя вроде есть (если у шарпистов это называется дефолтным конструктором)
>Придется на каждый пук писать конвертер.
так часто пукаешь что ли?
тащить доп зависимость из-за того что лень написать 0-1 конвертер...
>>2649578 (OP)
>>2649578 (OP)
>>2649578 (OP)