Тут надысь пришлось заняться парсинком свифта. Кошмар! Де-факто толькод одна либа для собственно парсинга (prowider), но после неё перелопатить данные в условно-обычные accounts/positions/transactions -- та ещё развлекуха с перепарсингом дюжины разных MT.
Где-то в глубинах подсознания: лет 25 назад я проходил мимо факта о том, что наиболее выгодной является система счисления на основе константы e (2.718281828...). Воплотить такое в практике невозможно из-за иррациональности константы. Из целочисленных систем троичная система ближе двоичной, и попытки воплотить были (см. заметку), но по историческим причинам всё пошло-поехало по двоичной системе.
Буквально по работе сталкивался (сталкиваюсь) с https://www.verisk.com/insurance/capabilities/weather-risk/wildfire/ , в 2000... 16-ом году, если правильно помню, слушал их доклад на конференции. Общее впечатление -- модели, конечно, есть, но пока не столь хорошо. Пост-мортем, после пожаров, можно провести анализ, но сами модели для предсказания пока были не на высоте. Изменилось ли что-то с тех пор -- могу на работе спросить, у нас этим каждый день занимаются.
Можель данных весьма "вширь" (скорее куст, чем дерево). Для пересчёта состояния всей системы надо зачитать, скажем так всё из базы. Если делать так, как это (было до версии 5 entity framework), то получалась cartesian bomb. Ну и сделал вместо чтения "одном запросом" разбивку на подзапросы. (В обратную сторону от вашего примера). Делов несложно (тот же хайбернейт так делает по умолчанию), но проблема не проявилась сразу: табличка, ещё табличка, ещё табличка.
Из полезного -- я какое-то время отлавливал профайлером бд дубликаты запросов.
Сперва деталь: спринг в этом примере совсем не нужен, только шум добавляет с заметке.
По делу: Наверное, стоит заметить, что предложенное решение скорее "да", чем "нет" для относительно небольших рекордсетов. Если зачем-то (случаи разные бывают) надо засосать 10к клиентов, у каждого из которых по пять имелов, десять контактов контактов, три телефона, четыре адреса, то перерабатывать такое "одним джоином" становится слишком плохо. Где граница? В каждом проекте/задаче своё.
Я это пишу ровно потому как около года назад вырезал подобное из кода в противоположную сторону.
UnixUtils
uutils
...
git/bash
Это всё прекрасно работает в Windows, и там всё это можно делать. В PS тоже можно, конечно.
"Вот и выросло поколение".
Когда-то "библией winapi разработки" были книжки Рихтер, Solomon&Russinovich. Полагаю, что и сейчас можно взять теперь уже древнюю книжку Рихтера и спокойно шаг за шаком повторить начала из книги, или прямо мсдн https://learn.microsoft.com/en-us/windows/win32/learnwin32/winmain--the-application-entry-point
А эта "заметка" не тянет даже на intro в тему.
До сих пор собираю Demos Commander под фрибздой. "Пусть будет".
Собственно вот новость:
https://theins.ru/news/262029
У вас не просто АД, а Керберос:
https://learn.microsoft.com/en-us/sql/connect/jdbc/using-kerberos-integrated-authentication-to-connect-to-sql-server?redirectedfrom=MSDN&view=sql-server-ver16
Отправленный по UDP пакет считается гарантированно полученным через 7 дней после отправки.
Ну как же, на 90%* заместили
* по массе
Тут надысь пришлось заняться парсинком свифта. Кошмар!
Де-факто толькод одна либа для собственно парсинга (prowider), но после неё перелопатить данные в условно-обычные accounts/positions/transactions -- та ещё развлекуха с перепарсингом дюжины разных MT.
Что в них отчечественного? Сборка линукса? Отвертка, которой корпус закручивали?
А можно просто закрыть глаза, поднять руку, резко опустить её, произнося одновременно:
— Да и шут с ней, с этой кармой!
Это — самое простое и правильное решение.
>> В Европе предложили сканировать устройства пользователей
>> Идею практически сразу раскритиковали в Совете ЕС и Европейском надзорном органе по защите данных
Где-то в глубинах подсознания: лет 25 назад я проходил мимо факта о том, что наиболее выгодной является система счисления на основе константы e (2.718281828...). Воплотить такое в практике невозможно из-за иррациональности константы. Из целочисленных систем троичная система ближе двоичной, и попытки воплотить были (см. заметку), но по историческим причинам всё пошло-поехало по двоичной системе.
Ну, за Россельхозбанк
Буквально по работе сталкивался (сталкиваюсь) с https://www.verisk.com/insurance/capabilities/weather-risk/wildfire/ , в 2000... 16-ом году, если правильно помню, слушал их доклад на конференции. Общее впечатление -- модели, конечно, есть, но пока не столь хорошо. Пост-мортем, после пожаров, можно провести анализ, но сами модели для предсказания пока были не на высоте. Изменилось ли что-то с тех пор -- могу на работе спросить, у нас этим каждый день занимаются.
>> в глазах иностранных инвесторов
Иностранных инвесторов. Записал.
В моём случае это .net, но смысл тот же.
Ровно, как описал.
Можель данных весьма "вширь" (скорее куст, чем дерево). Для пересчёта состояния всей системы надо зачитать, скажем так всё из базы. Если делать так, как это (было до версии 5 entity framework), то получалась cartesian bomb. Ну и сделал вместо чтения "одном запросом" разбивку на подзапросы. (В обратную сторону от вашего примера). Делов несложно (тот же хайбернейт так делает по умолчанию), но проблема не проявилась сразу: табличка, ещё табличка, ещё табличка.
Из полезного -- я какое-то время отлавливал профайлером бд дубликаты запросов.
Сперва деталь: спринг в этом примере совсем не нужен, только шум добавляет с заметке.
По делу:
Наверное, стоит заметить, что предложенное решение скорее "да", чем "нет" для относительно небольших рекордсетов. Если зачем-то (случаи разные бывают) надо засосать 10к клиентов, у каждого из которых по пять имелов, десять контактов контактов, три телефона, четыре адреса, то перерабатывать такое "одним джоином" становится слишком плохо. Где граница? В каждом проекте/задаче своё.
Я это пишу ровно потому как около года назад вырезал подобное из кода в противоположную сторону.