mayton2019

Без кода никто этот вопрос решать не будет потому что для симуляции этой ошибки надо код написать.
Я не знаю таких энтузиастов которые сядут и за ништяк напишут. Но по поиску olx parser в гитхабе есть
проекты. Можете посмотреть как у них реализован сбор телефонов.

https://github.com/digitalashes/olx-parser

Ну... если проводить аналогию с потоками. То count будет иметь столько экземпляров сколько
корутин запущено. Тоесть счетчик локальный по отношениию к функции.

И поскольку textView - это глобальный объект. Его видят все функции то они начинают его бомбить
разными значениями.

Хз. Но NTLM считается уже не безопасным для современных требований. Может поэтому?

Такая ошибка бывает когда ты используешь смесь из двух разных API. Из API локального времени и времени
с указанием тайм-зоны.

Лечится это переходом всех функций в какой-то единый API.

Обычно разработчики гугло-поисков обычно используют этот API
https://developers.google.com/custom-search/v1/overview

Насчет мульти-доменного поиска - не помню такого. Надо искать в описании.

проц грузился сильнее видеокарты

Ты не можешь сравнивать нагрузки проца и видеокарты. У них стоят разные задачи.
В общем случае играя в игру можно говорить просто о положительной корреляции
нагрузки. Но больше никаких нет предположений. И вряд-ли производитель игры
сможет дать какие-то комментарии по ситуации. Он тоже ничего не знает и расчитывает
на среднее железо в среднем сегменте потребления.

Про что данный вопрос? Про разработку или проектирование? Я могу сказать что при разарботке 100%
нужного материала лежит в исходном коде. В git. Документация может быть или может не быть но код это - golden
source. Код - это источник правды. Во всех спорных случаях лезут в код и сравнивают. И в концепии современного Scrum/Agile код идет впереди. Бизнес говорит
что delivery процесс важнее документирования. Сначала релизиться фича а потом вдогонку добиваются
wiki, confluence, autodocs. А после того как концепции IAS не только код но и инфраструктура тоже переехала
из с настенных плакатов и Word документов в нормальные себе *.yaml файлики. Для случая автора цена
вопроса - просто создать такой файлик и со всеми договориться что вот топики будут лежать здесь. Дальше
этот файлик можно брать как Properties, процессить делать кодогенерацию и прочее.

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

Добро пожаловать в мир крипто-панков. Поскольку государства и минфин никак не замечают криптовалюты
то скорее всего нет единого реестра их названий. По сути сегодня арбитром криптовалют могут выступать
биржи или обменники. Но они - тоже прослойка.

Я вообще сомниеваюсь что есть правильный ответ на этот вопрос. Попробуй переведи самую мелкую
долю монеты и проверь заходит ли она или нет.

HTTP ответы не обязаны являться текстом. Смотри в заголовки ContentType в ответах.
Если там к примеру стоит application/octet-stream - то это просто поток байтов. Может
быть бинарным кодом.

Как сделать генерацию случайного числа в диапазоне без повторений?

Способов - великое множество. Например если тебе нужно от 1000 до 2000 то
можно просто взять последовательность от 1000 до 2000 и например перевернуть
в нем местами десятичные цифры.

Мы получим псевдо-случайную неповторяющуюуся последовательность. Хотя на глаз
ее случайность будет весьма условной. Чуть сложнее - можно брать за образец LFSR
семейство генераторов. Это - свиговый регистр. Здесь желательно бы играть не с
десятичными диапазонами а работать в рамках битов внутри машинного регистра.

Вобщем критериев качества для такого ГПСЧ много. Период например. Или авто-корреляция
между соседними значениеми в последовательности. Если рисовать например
звездное небо из LFSR то звезды будут выстраиваться в какие-то очевидные
полоски.

Гибизов предложил очень хороший вариант с shuffle массива чисел. Он рабочий хотя и требует
массива для хранения.

Думаю что есть методы и посложнее но задание автором поставлено так неграмотно
что тут надо просто больше обсуждать именно его на не ГПСЧ.

Запуск в случайное время - это такая себе наивная попытка сделать балансировку нагрузки.
А хочется спросить что будет если случайность оказалась не очень удачливой и мы все таки
пересекаемся с другим джобом? Тут лучше бы все-таки сделать retry-logic с повторами
что если существует mutex, file, socket или еще бох знает какой разделяемый объект
то мы берем паузу на 5 минут и потом просто делаем повтор попытки.

Да можно. Почему нет. Так-же как и ссылку передавай содержимое файла. Просто длинная строка с переносами.

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

Надо посмотреть что за шум. Есть шум типа недостаточная экспозиция. При слабом свете была сделана фотка
и по ней цветные пиксели появляются. Свойство света мать ево. Корпускулярные свойства. Частица попала
только на красный либо линий либо зеленый элемент. Тут наверное будет один алгоритм фильтрации.

Если шум вида пыль и царапины на отсканированном фото - то это наверное будет другой фильтр.

Шум может быть низко-частотный. Цветовой блик или пересвет части изоборажения с уголка. Солнце в линзу попало.

Логотип фото-хостинга я-бы тоже считал шумом да. :) Смотря под каким углом смотреть на проблему.

Digital Signature с авторскими правами :) Тоже типа шум. Смотря для кого. :)