Ну, я бы сказал «странно», ибо уже могли бы допилить парсеры до понимания, что не надо весь dictionary тащить в клиента, если поля не указаны в каунте.
Я-то, по старой привычке, пользуюсь, но не думал, что имеет смысл.
Я в одну контору как собеседовение, решал задачу. Даны размеры доски (K x N), дан произвольный набор фигур (не только ферзи). Найти все решения. Написать на языке, которым не пользовался до тех пор в практике. (Я писал на Ada).
Следующий шаг — собрать небольшой проект из пары тысяч файлов, подтянув с местного репозитория энное количество библиотек, протянуть тесты, подложить нужные конфиги, подложить плетформ-депендант нейтив библиотеки, задеплоить в продакшн, заодно дёрнув какую джиру.
Модели наводнений вобщем есть и работают. Впервую очередь, важна детальная картография — уровни высот, где какие мосты (то есть важно видеть не паресечение дорог на карте, а что это мост на оврагом глкбиной в 2-3 метра, по дну которого идёт дорожка). В Англии, к примеру, хорошо разработана модель. Работает. Опять же, важно понимать, какое наводнение? Storm surge? Precipitation? много всего.
Это AI-шку хорошо бы сопоставить с/натравить на известные модели, которые использует AIR, и сравнить с известными историческими событиями.
Я активно мониторю (рсс-ом, грубо говоря) всякое фото-оборудование и последнее время замечаю какие-то аномальные продажи. Приведу пример:
— Лот на объектив на contax 645, по достаточно низкой цене, ставка, сообщение от ибея, что акк взломан, запрос на возврат, возврат
— Лоты от разных продавцов в разных странах с одинаковыми фотами (не японские продавцы, которые размещают на разных площадках, а именно что какие-нибудь Франция и Италия)
— Лоты на объективы с неадекватно-низкими стартовыми ценниками сфотканные на одном фоне, с непонятной историей размещения-съёма лотов (например www.ebay.de/itm/273930485675 )
Если я правильно понимаю, бывает случае, когда под редкими, мало кому нужными товарам могут прятаться продавцы, эхм, субстанций, или просто для мелкого отмывания денег.
Я повторюсь — Вы написали «бек-енд» МС шэйрпоинт, гугл-драйв, что-то там оффис 365 с облачным диском, т.п. Вопрос не в самом бекенде, а в том, как перевести пользователей с
1. это счёт
2. это счёт от брокера Икс
3. это счёт от брокера Икс за Июнь
4. это счёт от брокера Икс за Июнь из портфолио Игрек
5. это счёт от брокера Икс за Июнь из портфолио Игрек за потери по инструментам типа Зед
на плоскую структуру тегов, предоставив им возможность удобного поиска. В примере выше — это 1 и 2 и 3 и 4 и 5 с параметрами. Это безумно удобно для автоматизации процесса (это то, что нужно мне), но не столь очевидно-удобно для пользователей.
Я просто буквально сейчас работаю над подобной задачей в прожекте, где мне надо дать пользователям возможность искать-отслеживать документы на ФС из веба, но документы в ФС попадают не через веб, а вполне себе самостоятельно.
В моём случае это:
Привет sharepoint, тот же гуглдрайв api и всё такое.
Одна проблема — пользователи за 20-30+ лет работы с иерархией крепко на неё подсели. Сломить вот это вот «хочу фолдерА/фолдерЗед/.../документ» достаточно сложно (вопрос нужно ли) в пользу «найти по тегам».
Я-то, по старой привычке, пользуюсь, но не думал, что имеет смысл.
docs.microsoft.com/en-us/sql/integration-services/sql-server-integration-services?view=sql-server-ver15
www.youtube.com/watch?v=a2axIxq0QM4
Но было бы интересно узнать — а зачем? В чём, тысызыть, цимес?
Следующий шаг — собрать небольшой проект из пары тысяч файлов, подтянув с местного репозитория энное количество библиотек, протянуть тесты, подложить нужные конфиги, подложить плетформ-депендант нейтив библиотеки, задеплоить в продакшн, заодно дёрнув какую джиру.
150 (сейчас 181) — это ни о чём
Модели наводнений вобщем есть и работают. Впервую очередь, важна детальная картография — уровни высот, где какие мосты (то есть важно видеть не паресечение дорог на карте, а что это мост на оврагом глкбиной в 2-3 метра, по дну которого идёт дорожка). В Англии, к примеру, хорошо разработана модель. Работает. Опять же, важно понимать, какое наводнение? Storm surge? Precipitation? много всего.
Это AI-шку хорошо бы сопоставить с/натравить на известные модели, которые использует AIR, и сравнить с известными историческими событиями.
Буквально пару недель как и on prem, Azure DevOps Server 2019, не обязательно облако
Я активно мониторю (рсс-ом, грубо говоря) всякое фото-оборудование и последнее время замечаю какие-то аномальные продажи. Приведу пример:
— Лот на объектив на contax 645, по достаточно низкой цене, ставка, сообщение от ибея, что акк взломан, запрос на возврат, возврат
— Лоты от разных продавцов в разных странах с одинаковыми фотами (не японские продавцы, которые размещают на разных площадках, а именно что какие-нибудь Франция и Италия)
— Лоты на объективы с неадекватно-низкими стартовыми ценниками сфотканные на одном фоне, с непонятной историей размещения-съёма лотов (например www.ebay.de/itm/273930485675 )
Если я правильно понимаю, бывает случае, когда под редкими, мало кому нужными товарам могут прятаться продавцы, эхм, субстанций, или просто для мелкого отмывания денег.
1. это счёт
2. это счёт от брокера Икс
3. это счёт от брокера Икс за Июнь
4. это счёт от брокера Икс за Июнь из портфолио Игрек
5. это счёт от брокера Икс за Июнь из портфолио Игрек за потери по инструментам типа Зед
на плоскую структуру тегов, предоставив им возможность удобного поиска. В примере выше — это 1 и 2 и 3 и 4 и 5 с параметрами. Это безумно удобно для автоматизации процесса (это то, что нужно мне), но не столь очевидно-удобно для пользователей.
Я просто буквально сейчас работаю над подобной задачей в прожекте, где мне надо дать пользователям возможность искать-отслеживать документы на ФС из веба, но документы в ФС попадают не через веб, а вполне себе самостоятельно.
В моём случае это:
Фактически, вот эти вот 22978 — это теги, где часть тегов, грубо говоря даты, а другие, например, имена контрагентов, то есть по сути — переменные.
Одна проблема — пользователи за 20-30+ лет работы с иерархией крепко на неё подсели. Сломить вот это вот «хочу фолдерА/фолдерЗед/.../документ» достаточно сложно (вопрос нужно ли) в пользу «найти по тегам».