Ну неужели надо все разжевывать? Последующие комменты несут то же посыл и их плюсуют, а пытаешься кратко объяснить, что надо думать перед тем, как написать кусок кода — минус. Слепое следование правилам этикет несет отрицательный посыл и умаляет профессионализм разработчика.
Что можете сказать, например, по поводу оверхеда? Некоторые правила хорошего тона отнимают у заказчика лишние средства в виде избыточности ресурсов, поддерживающих «красивый» код.
Помню, в детстве очень не любил мультфильмы, где персонажами с теми самыми мультяшными чертами лица выполняли какие-то взрослые действия. Такие мультфильмы в итоге просто портили настроение. Это я к тому, что определяющим является контекст изображения и того места, где оно размещено, а не абстрактное восприятие отдельных его элементов.
Баланс между изображениями с лицами и без лиц будет сложнее сохранять в далёкой перспективе. Плюс, дополнительную нагрузку будет оказывать совмещение изображений с лицами и без лиц, а также их чередование.
Либо стоит изначально определять регламент, где будут описаны условия, при которых изображения не могут находиться рядом или чередоваться. Либо всегда использовать изображения с лицами, но с разной степенью детализации черт.
Хотя… я вот сейчас подумал, а ведь сквозная реклама вполне возможна… если клиент в профиле почты указал еще и свой телефон.
Но, тут речь о другом, все эти базы — абстракция. Вы обращаетесь к сервису и говорите, у нас отоварилось сто человек, вот их номера, подберите нам пожалуйста еще десять тысяч человек, которые точно купят наш товар. И по «шаманским» алгоритмам сервис возвращает, по его мнению, похожих людей. Но часто выходит, что это просто тыканье пальцем в небо.
Перечитал еще раз статью (может быть я что-то упустил; на самом деле по тексту много нюансов, но некритичных), пришлось разобраться с сервисом «Аудитория». Надеюсь этот ответ будет исчерпывающим.
Во первых, БКИ не использует сервис «Аудитория» однозначно, сервис работает по принципу от общего к общему, а БКИ нужно от частного к частному. Между Яндексом и БКИ должен быть договор иного рода. Тем более на выходе у БКИ все равно будет некий «коэффициент лояльности» и им в руки никогда не попадут личные данные, собранные Яндекс. Разговор между ними условно выглядел так: давайте, мы вам мыло или телефон клиента, а вы нам число от 0 до 10, кому можно кредит давать, а кому нет. Как вы там это будете считать, с помощью толпы математиков или шамана с бубном нас не интересует, но чтобы данные были точные (речь про коэффициент, просто число).
Во вторых, сервис «Аудитория» работает иначе — вы загружаете туда телефон одного человека, а он вам возвращает тысячу человек похожих на того, которого вы туда загрузили. И чем конкретней вы будете подбирать клиентов для загрузки, тем точнее вам сервис вернет подходящую аудиторию. И учитывайте, что данные об аудитории вы не получите, Яндекс сам доставит рекламу предполагаемой аудитории. Также замечу, что на скриншоте опущен комментарий к форме: «Файл должен включать не менее 1 000 записей и соответствовать требованиям.», что дает большую ясность картины.
В третьих, частичное хэширование данных (номер, почта) при загрузке файла в сервис предназначено для защиты тех клиентов, которых вы загружаете в сервис. Это, примерно, на тот случай, если у вас в офисе отключили интернет и вы попросили прохожего загрузить данные с флешки в соседнем интернет кафе. Данные сильно короче хэша — просто защита от дурака.
И замечу, что я ни коим образом никого не защищаю, просто при более детальном рассмотрении возникают некоторые несоответствия.
Ошибкой яндекса было указывать в подсказке рабочие хэши, если это, правда не коллизии на номера.
История этой деперсонализации длинная, но это можно сравнить, например, с блюром — по контурам можно определить ту или иную категорию, но точный рисунок уже получить невозможно. И здесь то же самое, вы просите Яндекс показать рекламу тем, кто в блюре похож на квадрат или треугольник. Но вы никогда не узнаете кому он ее показал. По этому рекламодатели проводят свои опросы — как вы о нас узнали, из рекламы в интернете, ага и ставят плюсик. А потом сравнивают цифры рекламных источников и понимают сработала эта таргетированая реклама или нет.
Есть один нюанс. Как часто вы читаете договор оферты, когда регистрируетесь в том или ином приложении? Чаще всего, в каждом из них прописан пункт на право использования данных организатором или его партнерами (в соответствии с ФЗ конечно). Просто организатор умалчивает, кто являются его партнерами.
Вынужден с вами не согласиться. Суть я как раз понял, но вы, также, как и ТС, видимо, не совсем представляете принцип хэширования данных. Поясняю: хэш строится на основании последовательности байт, переданных в функцию и именно байт, а не символов. А вот что из себя представляет эта последовательность байт — это большой вопрос.
Наглядный пример
Номер телефона в следующих примерах: 88001234567
Передан в виде текстовой строки, где каждый байт представляет собой символ из таблицы ASCII, соответствующий каждой цифре номера — 2d6895b3050243a6150c87cad8825655
Передан в виде текстовой строки, где каждые два байта представляют собой символ из таблицы UCS-2 BE (Unicode), соответствующий каждой цифре номера — e8c7f423b90a8f01cb02174e5a369c0a
Передан в виде текстовой строки, где каждые два байта представляют собой символ из таблицы UCS-2 LE (Unicode), соответствующий каждой цифре номера — 891b3d0cffe18d8cc22dfbc97878992d
Передан в виде последовательности байт, где каждый байт представляет собой число, соответствующее каждой цифре номера — 804584012e982aa00830a73937b86bf1
А это бонус, здесь каждые полбайта представляют собой число, соответствующее каждой цифре номера — c2d2df9d446ed5e221e577dabde95667
И вот скажите мне пожалуйста, какой из вариантов правильный? Вероятнее всего, вам покажется, что это четвертый пункт. Но это не так. Здесь нет правильных и неправильных вариантов — все они пригодны для хэширования данных. Все зависит от автора кода и техпроцесса, в котором эти данные передаются. Замечу, что четвертый (и тем более пятый) пункт более сложен в реализации, так как данные от пользователя в преобладающем большинстве поступают в текстовом виде и преобразовывать их в числовую последовательность никто специально не будет. Соль суть хэширования в том, что исходные данные знает только то лицо, которое их хэширут и то лицо, для кого эти данные предназначены.
Про джейсон вы не совсем поняли, данные можно представить и так:
{"phone": "88001234567"}
Здесь хэшировать строку можно прямо в таком виде (hash: 1772667c4aa2de4b3ff097903884aa9e).
Следовательно, автору статьи нужно точно знать, что из себя представляли данные на входе хэш-функции, чтобы получить тот же номер, а не случайный набор цифр.
Спасибо за сомнение — заморочился на пример. И не лень ведь было. :D
С дешифровкой хэшей вы занимаетесь ерундой — кто сказал, что подсчет производился на данных в бинарном виде, это мог быть юникод, джейсон и много чего ещё. Тут и соль никакая ненужна.
А передача данных сторонним организациям по партнёрскому договору с ними, официально прописана в этом самом договоре…
С радостью плюсанул бы, если бы была такая возможность.
Ждём от автора в ближайшем будущем новый язык, в котором все будет)
А потом длинную идеологическую телегу, про то почему этого «всего» нет))
Лично я в какой-то момент перестал обращать на это внимание, нет этого — есть что-то похожее, напрягает лишь то, что эти различия обращают твое внимание на индивидуальность языка. Может суть в этом?
Пожалуй, такие компиляции идей всегда мнение субъективное. Например не могу согласиться с информативными именами функций — быстрее чтение кода, как быстрое чтение книг, мозг цепляется за первые и последние буквы слова и плюс учитывает его форму. Длинные имена же заставляют их перечитывать полностью и заострять на этом внимание, снижая скорость чтения.
Использование экземпляров классов вместо функций с параметрами — та же история. По функции с параметрами гараздо проще понять что она должна сделать, нежели метод, с объявленными где-то там атрибутами.
Книгу не читал и не буду настаивать на ее необъективности, но чаще всего это книги для общего развития.
Вся эта реализация просто бессмысленна. А главное преследует цель эстетизации, а не оптимизации. И чем вам помешали массивы? Учитывая, что набор функций для их обработки уже собран. Напоминает типичную ооп'о'фагию…
К сожалению тема не из области моих интересов, но если необходимо работать с данными, которые могут содержать ошибки, я руководствуюсь правилом — скорость записи всегда ниже чтения, запись производится один раз и предварительная обработка должна выполняться на этом этапе. Используйте поля-флаги для обозначения ошибок, либо дублирующие поля с корректными данными. Жертвуя некоторой избыточностью можно избежать систематического поиска ошибок в дальнейшем.
Тут как раз совсем наоборот, мутация в том или ином гене может привести к кардинальным изменениям сразу. Но в подавляющем большинстве случаев это ведёт к гибели особи. И в самом редком случае это может дать особи превосходящие способности по отношению к другим особям из того же вида. Дальнейшее развитие вида, очевидно, будет развиваться в этом направлении.
Это как лотерея — миллиарды шариков в барабане и какой-то из них с призом.
Чтобы знать про рычаги не нужно читать учебник. Вся ценность собранных знаний в том, что их не нужно каждый раз придумывать.
Напомнили мне случай из далёкого детства — чтобы облегчить себе работу по измерению длины окружности различных предметов, не прикладывать каждый раз нитку, а потом измерять ее длину, я нашел зависимость между диаметром и длиной окружности. Это был коэффициент со значением 3.14. А в школе потом узнал, что изобрел небольшой «велосипед».
Исходя из того, что я об этом не знал и никогда не слышал, но знание это получил самостоятельно — я инопланетянин?
Есть у нас сервак с сетевухой на 82574 — писал когда-то скрипт, который по расписанию удаляет интерфейс из системы и ставит его обратно. Теперь ясно где собака зарыта))
Баланс между изображениями с лицами и без лиц будет сложнее сохранять в далёкой перспективе. Плюс, дополнительную нагрузку будет оказывать совмещение изображений с лицами и без лиц, а также их чередование.
Либо стоит изначально определять регламент, где будут описаны условия, при которых изображения не могут находиться рядом или чередоваться. Либо всегда использовать изображения с лицами, но с разной степенью детализации черт.
Но, тут речь о другом, все эти базы — абстракция. Вы обращаетесь к сервису и говорите, у нас отоварилось сто человек, вот их номера, подберите нам пожалуйста еще десять тысяч человек, которые точно купят наш товар. И по «шаманским» алгоритмам сервис возвращает, по его мнению, похожих людей. Но часто выходит, что это просто тыканье пальцем в небо.
Во первых, БКИ не использует сервис «Аудитория» однозначно, сервис работает по принципу от общего к общему, а БКИ нужно от частного к частному. Между Яндексом и БКИ должен быть договор иного рода. Тем более на выходе у БКИ все равно будет некий «коэффициент лояльности» и им в руки никогда не попадут личные данные, собранные Яндекс. Разговор между ними условно выглядел так: давайте, мы вам мыло или телефон клиента, а вы нам число от 0 до 10, кому можно кредит давать, а кому нет. Как вы там это будете считать, с помощью толпы математиков или шамана с бубном нас не интересует, но чтобы данные были точные (речь про коэффициент, просто число).
Во вторых, сервис «Аудитория» работает иначе — вы загружаете туда телефон одного человека, а он вам возвращает тысячу человек похожих на того, которого вы туда загрузили. И чем конкретней вы будете подбирать клиентов для загрузки, тем точнее вам сервис вернет подходящую аудиторию. И учитывайте, что данные об аудитории вы не получите, Яндекс сам доставит рекламу предполагаемой аудитории. Также замечу, что на скриншоте опущен комментарий к форме: «Файл должен включать не менее 1 000 записей и соответствовать требованиям.», что дает большую ясность картины.
В третьих, частичное хэширование данных (номер, почта) при загрузке файла в сервис предназначено для защиты тех клиентов, которых вы загружаете в сервис. Это, примерно, на тот случай, если у вас в офисе отключили интернет и вы попросили прохожего загрузить данные с флешки в соседнем интернет кафе. Данные сильно короче хэша — просто защита от дурака.
И замечу, что я ни коим образом никого не защищаю, просто при более детальном рассмотрении возникают некоторые несоответствия.
Ошибкой яндекса было указывать в подсказке рабочие хэши, если это, правда не коллизии на номера.
История этой деперсонализации длинная, но это можно сравнить, например, с блюром — по контурам можно определить ту или иную категорию, но точный рисунок уже получить невозможно. И здесь то же самое, вы просите Яндекс показать рекламу тем, кто в блюре похож на квадрат или треугольник. Но вы никогда не узнаете кому он ее показал. По этому рекламодатели проводят свои опросы — как вы о нас узнали, из рекламы в интернете, ага и ставят плюсик. А потом сравнивают цифры рекламных источников и понимают сработала эта таргетированая реклама или нет.
И вот скажите мне пожалуйста, какой из вариантов правильный? Вероятнее всего, вам покажется, что это четвертый пункт. Но это не так. Здесь нет правильных и неправильных вариантов — все они пригодны для хэширования данных. Все зависит от автора кода и техпроцесса, в котором эти данные передаются. Замечу, что четвертый (и тем более пятый) пункт более сложен в реализации, так как данные от пользователя в преобладающем большинстве поступают в текстовом виде и преобразовывать их в числовую последовательность никто специально не будет.
Сольсуть хэширования в том, что исходные данные знает только то лицо, которое их хэширут и то лицо, для кого эти данные предназначены.Про джейсон вы не совсем поняли, данные можно представить и так:
Здесь хэшировать строку можно прямо в таком виде (hash: 1772667c4aa2de4b3ff097903884aa9e).
Следовательно, автору статьи нужно точно знать, что из себя представляли данные на входе хэш-функции, чтобы получить тот же номер, а не случайный набор цифр.
Спасибо за сомнение — заморочился на пример. И не лень ведь было. :D
А передача данных сторонним организациям по партнёрскому договору с ними, официально прописана в этом самом договоре…
Ждём от автора в ближайшем будущем новый язык, в котором все будет)
А потом длинную идеологическую телегу, про то почему этого «всего» нет))
Лично я в какой-то момент перестал обращать на это внимание, нет этого — есть что-то похожее, напрягает лишь то, что эти различия обращают твое внимание на индивидуальность языка. Может суть в этом?
Использование экземпляров классов вместо функций с параметрами — та же история. По функции с параметрами гараздо проще понять что она должна сделать, нежели метод, с объявленными где-то там атрибутами.
Книгу не читал и не буду настаивать на ее необъективности, но чаще всего это книги для общего развития.
Для меня очевидная вещь, не за что)
Это как лотерея — миллиарды шариков в барабане и какой-то из них с призом.
Напомнили мне случай из далёкого детства — чтобы облегчить себе работу по измерению длины окружности различных предметов, не прикладывать каждый раз нитку, а потом измерять ее длину, я нашел зависимость между диаметром и длиной окружности. Это был коэффициент со значением 3.14. А в школе потом узнал, что изобрел небольшой «велосипед».
Исходя из того, что я об этом не знал и никогда не слышал, но знание это получил самостоятельно — я инопланетянин?