forced, ну вот потому и советуют медиану, так как во многих отношениях она лучше отражает ситуацию. Например, в статистиках о зарплате часто указывают отдельно среднюю и медианную - и если они сильно расходятся, значит, есть перекосы или в получающих особенно много, или в получающих особенно мало.
Как правильно тут поступать я не очень понимаю, так как в матстатистике всегда разбирался не очень хорошо и за экзамен по ней получил когда-то тройку. Мне самому обычно приходилось решать узкие проблемы "выяснить что-то один раз", поэтому я, например, перебирал порог перцентиля вручную, пока он не подскакивал резко особенно сильно - тут и было видно, где начинается нетипичное меньшинство.
dofoh88849, это не поможет, так как подобные расширения не ресолвят ничего через DNS, и вообще использование слова "VPN" применительно к браузерным расширениям некорректно: это прокси, а не VPN. Иногда это реализуется даже через явное использование каких-то прокси (обычно socks5), прошитых в расширении или получаемых им по API от владельцев расширеня, иногда же запросы оборачивают в другие запросы. В любом случае, фильтровать тут разве что API-сервера расширения или подсовываемый им прокси, что нетривиально и не поможет при частой их смене.
forced, медиана - это граница величины, при которой половина выборки имеет значение величины меньше границы, а половина - больше.
Более общий случай - перцентиль - где вместо половины выбирается указанный процент. Например, перцентиль 80% - это величина, ниже которой 80% выборки. Медиана - это перцентиль 50%.
Например, пусть у нас выборка сроков доставки посылок почтой. Допустим, 90% посылок доставляется за неделю, 8% - от недели до месяца, 1% от 1 месяца до 12, 1% не доставляется в пределах срока страхования посылок (потеряшки). Тогда перцентиль 90% - 1 неделя, 98% - месяц, 99% - 12 месяцев. А среднее время доставки при этом бесконечно - ведь некоторые посылки не доставляются вообще. Если даже выкинуть потеряшки или считать что они получили финальный статус доставки "потеряно" через 12 месяцев, то получится, что каждая задержавшаяся на год посылка вкладывает в срок доставки в средний показатель как минимум 52 посылки в 90% части выборки - очень прилично искажается среднее время доставки от каждой потеряшки.
Поэтому подобные показатели часто рассматривают с точки зрения перцентилей.
В примере из вопроса перцентиль 90% будет 8 метров, в то время как среднее может быть например 13.6 (если в 90% среднее 4 метра, а в 10% оставшихся у всех 100 метров, то 4*90+10*100=1360, делим на 100 и получаем 13.6).
Greenberg2, вполне серьёзно, маркетплейсы активно борются с парсингом. В том числе показывая капчу, блокируя доступ итд итп. Поэтому парсящие всё более и более изощрённые методы используют, с кучами купленных мобильных проксей итд итп.
В китайском интернете некоторые крупные сайты вообще могут показать капчу "сдвиньте вот эту полосочку" прям при первом посещении.
То, что товар был слит за рубль, самому маркетплейсу не особо важно, это проблема продавца, кому он продал. Но совсем ничего с этим не делать они тоже не могут, так как продавцы в таком случае не будут продавать за рубль вообще ничего, ибо зачем выставлять товар, если он будет моментально куплен ботами и не увиден обычными людьми?
Наибоее правильный ответ - не надо редактировать файлы внутри запущенного или остановленного контейнера вообще. Это не докер-вэй. Надо редактировать файл не в контейнере, а в репозитории образа или сборочной песочнице, а затем собирать образ заново. И приучать себя к мысли, что докер-контейнер всегда при изменениях пересоздаётся, это непостоянная сущность.
CityCat4, да, я понимаю, я работал админом в госконторе, правда в Москве, и для нас прям напрягались чтобы нам более-менее сносную зарплату сделать. Потому что все понимали, что приличные админы за гроши долго не задержатся.
gitPush, экземпляр php-интерпретатора на каждый запрос только в php-cgi, для php-fpm и всяких mod_php один процесс будет обрабатывать много запросов (как настроишь столько и будет, главное чтобы памяти хватило).
Reyn1984, в общем случае, скорее всего, ничего не получится. Ключом может выступать, например, серийник устройства или комбинация серийника и вон тех 10 байт по смещению в неочевидном месте недоступной части EEPROM плюс XOR с секретной строкой. Поэтому без устройства ключ не получишь, да и механизм его получения загрузчиком устройства может быть эзотерический.
Владислав Калужский, это нормально, я сам её никогда не читал. У нас были в университете практические занятия, где мы реализовывали какие-то методы сортировки (каждому студенту давали свой вариант), свои файловые системы (мне досталось на инодах с древовидной системой блоков), интерполяция функции одной и двух переменных, поиск собственных значений матрицы, QR/LU-разложения и всякое такое... Какие-то преподаватели давали основы TeX или сетевого взаимодествия (типа "напиши игру быки и коровы по сети"). Обучались на конкретных задачах, нередко математического содержания (по нашему основному профилю).
Олимпиадные задачки, интерфейсы, несложные игрушки, приложения для решения каких-нибудь несложных задач (ежедневник, музыкальный плеер итд итп) - этого за глаза хватит на текущем этапе. Не нужно браться за книги слишком высокого уровня.
В любой кникже по алгоритмам обязательно используются символика ассимптотики (типа O(n)), это в школе вообще никогда не проходят, кроме возможно очень крутых школ с математическим уклоном. Подобную терминологию и сопутствующую теорию надо изучать или в рамках полноценной программы высшего образования (то есть пойти в институт учиться), или осваивать самостоятельно. Но на начальном этапе это не нужно. Как-то решил задачу - уже хорошо.
Андрей Ширяев, на Android можно поменять в специальном файле только на рутованном устройстве. И то это не очень тривиально (там по-моему PDU в sqlite хранится).
Но реально, зачем это всё? Если обмануть суд - это вряд ли выйдет. Есть содержание SMS очень важно, то не будут полагаться на то, что видно на телефоне, а реально запросят оператора, который обязан всё и вся хранить три года. Если же задача другая - то расскажи, какая именно. Сейчас это очень смахивает на XY problem: вместо реальной задачи задаётся вопрос о своих попытках её решить каким-то весьма вероятно кривым способом.
oslik_ppc, вообще говоря, может быть не очень ок. Если код прям дублируется, то его лучше оформить как совместно используемый общий модуль. Но это, как обычно, не должно становиться самоцелью. Например, если у нас есть какая-то несложная функция на 10 строчек, которая тонет в 20 тыс. строчек непересекающегося кода обоих проектов, то усилия по выделению этого незначительного общего кода в отдельный репозиторий, подключаемый к этим проектам, могут быть совершенно неоправданы.
С другой стороны, наличие такого совпадающего микрокусочка кода может быть признаком либо того, что проекты принципиально разные и несвязанные между собой, либо что в них одни и те же вещи сделаны принципиально по-разному. И это может быть признаком архитектурно неудачных решений.
Например, в одном компоненте наворочено ORM, а в другом идёт работа многочисленными прямыми запросами к той же самой базе данных. Кода общего нет, но по факту есть две реализации работы с одной и той же базой. И внутри получаются почти такие же запросы, но разными способами и с излишним дублированием кода.
Или в одном компоненте всё построено на асинхронных вызовал async/await, а в другом - на синхронных задачах в тредпуле с коллбэками. То есть два архитектурных подхода, которые в итоге могут решать одни и те же задачи. Причём не всегда можно одно заменить другим. Например, если у нас в одном компоненте используется глубоко синхронная библиотека, то его может быть слишком сложно переделать на асинхронщину. Это, кстати, обычное узкое место рефакторинга: есть куча кода, который уже работает, но его архитектура не позволяет куски старого кода легко интегрировать в новую архитектуру.
Я раньше работал в организации, где делали собственную систему для решения различных задач, она была написана на php и восходила к разработке студента, который в начале нулевых писал код вообще без функций :) По мере усложнения было много боли по переделыванию этого всего на Zend Framework, классы, MVC и всё такое. И там прогеры как-то прилично усилий потратили, чтобы научиться корректно и без побочных эффектов вызывать из старого кода новый и наоборот, чтобы можно было рефакторить по частям, а не писать полностью идентичный аналог параллельно с поддержкой существующего.
Но если это собственный мелкий проект, затеваемый с нуля, то можно просто волевым решением выбирать изначальное единообразие, чтобы не создавать себе причин излишне страдать в будущем. Сразу стремиться к одинаковой работе с данными через единый модуль с ORM.
duo456, использование соли нужно не для ломания расшифровываемости, а для того, чтобы данные нельзя было подобрать по готовым таблицам.
Как это работает на простейшем примере хеширования паролей: пусть у нас используется MD5, тогда MD5("123")=202cb962ac59075b964b07152d234b70, и если у нас из миллиона пользователей 10 имеют пароль 123, то в базе будет 10 хешей с таким значением, которые легко найдутся по радужным таблицам. Но если каждый пароль будет посолен, то хеши станут разными. Например, MD5("nk4Wu3XUbNvf123")=3f39c284a3b16263ebcc50ada7148d3e и уже потребуются радужные таблицы намного большего объёма. Причём даже знание хеша+соль не поможет упростить задачу подбора.
Конкретно к шифровке-расшифровке. Мы добавляем случайную соль в исходный текст по каким-то конкретным, чтобы было понятно, где она заканчивается и как её выкинуть в итоге. Например, "соль:текст" или json'чиком {"text":"текст","salt":"соль"}. Если соль каждый раз будет случайной, то в результате расшифровки мы получаем текст с солью, которую можно выкинуть (она не имеет смысла, просто добавляется для увеличения энтропии шифротекста) и получить исходный текст. Но шифротекст при этом кардинально меняется.
Это может быть особенно ценно в протоколах, в которых передаются данные, принципиально допускающие повторения. Например, если передаются показания датчиков, то они ж могут повторяться.
Как правильно тут поступать я не очень понимаю, так как в матстатистике всегда разбирался не очень хорошо и за экзамен по ней получил когда-то тройку. Мне самому обычно приходилось решать узкие проблемы "выяснить что-то один раз", поэтому я, например, перебирал порог перцентиля вручную, пока он не подскакивал резко особенно сильно - тут и было видно, где начинается нетипичное меньшинство.