Как стать автором
Обновить
102
0.2
Slava Vedenin @vedenin1980

Java developer

Отправить сообщение
Да, некруглые суммы в магазине, уникальные — возможность деанонимизации. Но тогда станет очевидно что магазин заинтересован в вашей деанонимизации. Вы это чётко осознаёте и у вас есть выбор отказаться от его услуг.

Необязательно, приходя в супермаркет, я гарантировано получу некруглую сумму, просто потому что покупок много. Или я например, часто покупаю в одном магазине на разные суммы (например, 1201 руб, 3451 руб, 8421 руб) в разные даты. А так как частые покупки достаточно обычное явление можно провести анализ всех транзакций и обнаружить что соответствие моих снятых денег и пришедших в магазин. Скажем, в день в системе проходит 1 млн. транзакций из 4 цифр без копеек., то есть вероятность вычислить покупателя 1 к 100, но если сделать предположение, что я делаю покупки в магазине часто, то все упрощается. Особенно, если товары связанные, например три книги одного автора «том 1», «том 2», «том 3» и т.п.

Если магазин заинтересован в анонимности, то свои транзакции/чеки он может отложить на долгое время, получится некий store-and-forward. По крайней мере такая возможность есть

Во-первых, а если НЕ заинтересован? По идее, с действительно анонимной валютой можно оплатить скачивание нужной информации и быть уверенным, что ни банк, ни магазин не узнает кто ты есть. А ты получается что магазин на пару с банком может вычислить покупателя.
Во-вторых, что такое долгое время? Пока в этой системе нет особо большого кол-ва транзакций (скажем, не более 10 млн за неделю), то даже откладывание на неделю чека с уникальной суммой особенно не поможет, а больше сами клиенты ждать не захотят.

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

Во-первых, кто мешает вывести деньги в другую систему/наличные, а потом вернуть обратно? Во-вторых, можно при желании можно увеличить связку и до тысяч/десятков тысяч, где замучаешься разбираться где настоящий пользователь, где фейковый.
Да, в теории вы может выдавать чеки только определенных номиналов, скажем 1 копейка, 10 копеек, 1 рубль, 10 рублей, 100 рублей и т.д. Но все равно, стандартный сценарий — сформировал чеки, сразу оплатил в магазине. А в этом случае, как была сформирована сумма 2112,38 руб. в чеках, так она в магазин и пришла. Даже при круглых числах — какой шанс что кто-то ещё в тот же день заплатит 8 млн. рублей в Тюмени в этой системе за новый автомобиль? Система, где анонимность раскрывается при определенной сумме платежа или требующая ждать N дней/недель прежде чем купить товар, не сказать что очень удобная.
Этот анонимный, безопасный

Даже если представить что все работает как описано, анонимность достаточно сомнительна. Смотрите, банк знает суммы транзакций списаний с вашего счета и суммы пополнений в магазине. А этой информации вполне достаточно для деаномизации.

Предположим, вы решили купить товар в русскоязычном секс-шопе онлайн за 2112,38 руб., сразу сформировали чек и передали его магазину. Казалось бы, все анонимно, но у нас есть уникальное шестизначное число суммы. Предположим что система в России стала достаточно популярной и в ней происходит 10 млн. транзакций в день (то есть куда больше чем у Visa сейчас). С вероятностью 1/5 вас вычисляют (учитывая что чаще используются суммы 2000 или 1999, то и с большей вероятностью). Если учитывать что большинство пользователей сформировав чек, его сразу отдадут магазину, то есть вычисляют с вероятностью 100%. Плюс банк знает ваши паспортные данные, прописку, номер телефона и ip адрес (настоящий или поддельный не так важно), то есть с определенной вероятность сможет вычислить город где вы находитесь. Плюс, по анализу покупки достаточно легко и из десятка человек с большой вероятность выбрать нужного (подросток, старушка или мужчина вряд ли будет покупать новое платье) и т.п. То есть достаточно магазинам не использовать круглые суммы, как
вся анонимность идет лесом. А, естественно, желающие отслеживать анонимные транзакции (например, компетентные органы) заставят использовать банк и магазины такие цены.

Да, в теории можно сформировать чек и отложить его на год, а потом заплатить, но зачем такой головняк, если есть всякие анонимные виртуальные кошельки на которые можно кинуть наличных в любом терминале оплаты? Зачем нужна система единственный плюс, которой в анонимности, если по транзакциям легко обнаружить источник?

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

Кстати, в битконе никто же не мешает создать сотню кошельков и кидать деньги с одного на другой, получив таким образом анонимные кошельки (кто сможет понять какие кошельки ваши, а какие принадлежат посторонним? Может под каждый из сотни кошельков скрывается отдельный пользователь).
Там могут возникать весёлые моменты с join'aми, иногда проще отдельно заводить счётчик чем сталкиваться с таким

Это не веселые моменты, это просто кривые руки того кто пишет запрос.

Потому что, обычно, это 100% full table scan. Обычно проще заменить на UNION ALL, или на CROSS JOIN, типа так.

Вообще-то, там речь идет о full outer join, который мало кем используется, а вот left join в той же статье назван вполне нормальным, не говоря уже о том что left join на union all никак не заменяется.
просто потому что в этом обсуждении никто не собирается входить в моё положение

По опыту работы в очень крупной международной компании с многомиллардными таблицами в базе Oracl'a, где left join'ы использовались постоянно — с ними проблем не было, естественно если использовать правильные индексы и правильные запросы (не пытаться, например, получить всю таблицу без фильтров). Если бы при этом был реально full table или full index scan на многомиллиардной таблице все бы умерло сразу.
Скажем, так
Select B.*, A.* from A,B where A.date = today() and B.date = today() and B.id1 += A.id2.

Нормальный оптимизатор сначала обрежет A и B до today в результате речь будет идти не о полных таблицах на миллионы записей, а скажем о тысячах, потом сделает просто join (речь идет о десятках записей), потом просто выведет уже полученную таблицу B за сегодня легко модифицируя её общим join'ом.

При наличии индексов по date, id1 и id2 все будет быстро, большой разницы для оптимизатора между выводом просто join'a или join'a + таблица B в большинстве случаев не будет (там по сути всего лишь ещё один обычный join с двумя весьма небольшими таблицами и индексами на ключевые поля).
В случае с Outer Join'aми заполняется внешняя часть круга — соответственно для её формирования нужен full table scan, или fast full index scan.

Не нужен, достаточно определить пересечение A и B (обычный join) и наложить его на таблицу B и выдать результат. То есть, есть в таблице А и B по миллиону записей из них 10 общих. Мы получили эти 10 записей, запоминаем их, теперь возвращаем нужное кол-во строк таблицы B (например 100) с null вместо полей таблицы A, если встречаем индекс тех 10 записей, то подставляем вместо null нужные значения из А. В результате, сложность = обычный join А и B + обычный вывод данных таблицы B + небольшая подстановка из памяти.

Учитывая что обычно ещё накладывают фильтры where на A и B разница между обычным join и left join не существенна.

Можете привести пример? В случае, который я описал выше поле name для системы тоже не нужно, но его можно ввести для удобства отладки и читаемости json'a. Не вижу проблемы в добавлении поля. которого не планируем использовать в самой системе для повышения читаемости.

Я вижу следующие проблемы у json'a с комментариями:
1) Лишние преобразования, лишний код, лишние возможности для ошибок,
2) Невозможно отправить json c комментариями другим системам и организациям,
3) Скорее всего при отправке с веба на бек, все комментарии исчезнут,
4) Отсутствие комментариев при отладке приложения, так как они удаляются намного раньше,
5) Сложность валидации и форматирование на уровне IDE,
6) Нестандартная форма json'a, требующая привыкания,
7) Требование танцев с бубном при преобразовании форматов,

То есть json с комментариями можно использовать только для локальных конфигов, которые никуда не передаются и используются в рамках одной системы, но при этом нет проблемы комментарии добавлять как отдельное поля (в формате выше).
Ради интереса попробуем оба формата:

{
   "order1":"N 21", // Накладная на принтер
   "order2":"M 23", // Накладная на мышку
   "order3":"S 231", // Чек за пицу и пиво
}


{
   "order1"  : {
       "number": "N 21", 
       "name": "Накладная на принтер"
   },
   "order2": {
       "number": "M 23", 
       "name": "Накладная на мышку"
   },
   "order3": {
       "number": "S 231", 
       "name": "Чек за пицу и пиво"
   }
}


Не знаю, для меня второй вариант хотя и более длинный, но куда более человекочитаемый и понятный.
Почему вы считаете, что все привыкли к {question: value //comment}? Мне например более удобно читать правильный JSON c несколькими полями, тем более что IDE хорошо умеет форматировать именно валидный JSON, а руками делать переносы и отступы мучительно долго. А вот такой формат JSON с комментариями наоборот несколько неуютен для привыкших работать с правильным JSON'ом.

А так часто нужны комментарии именно к данным? Если вам нужно комментировать данные, то на мой взгляд стоит завести отдельное поле в JSON, где и комментировать данные.

Что проще понять:

{«question»:«42» //The Ultimate Question of Life, the Universe, and Everything}

или

{«question»:{«descripton»:«The Ultimate Question of Life, the Universe, and Everything», «value»:«42»}

Не вижу особого смысла в комментариях именно к данным, другое дело если нужно комментировать структуру.

Плюс такие данные в Json можно обрабатывать штатными средствами.
Есть такая вещь, как схема json, дополнительным плюсом она дает возможность не только комментировать, но и валидировать и указывать тип данных. Если установить за правило иметь для каждой отдельной структуры json свою схему с заполненным description, комментарии становятся уже не так критичны. Более того для десятков json с одной и той же структурой, нужна лишь одна схема с описанием, а не дублирование комментариев в каждом json. ИМХО, но это более надежно и просто, чем лишний костыль с регулярным выражением (которое может в какой-то момент оказаться не верным).
Да, для такого же магазина — есть товары, есть корзина, есть заказы, есть постоянные покупатели, есть скидки, есть отзывы и комментарии. Для создания правильной архитектуры, надо не только понимать какие есть сущности в системе, но и те бизнес процессы, которые с ними происходят (чтобы не продать двум покупателям одну и тут же последнею единицу товара со склада).
Не понимаю, почему заминусовали статью. В ней говориться о правильных вещах, и она многим может быть полезна.

Мне показалось, что статья слишком поверхностный пересказ MVC своими словами. Если уж писать не на СМС и не на готовом фреймворке, явно стоит самому сесть и прочитать о разных архитектурах веб. приложений, благо информации о MVC и т.п. более чем достаточно (в том числе на русском). Совсем новичок вряд ли осилит создание сайта с нуля, без СМС, а более-менее опытного разработчика статья скорее запутает, слишком там мало архитектуры.
Ну и в конце-концов, SQL это информационно-логический мультипарадигмальный язык, а вовсе не функциональный. В лучшем случае, функциональной частью можно назвать Select'ы с их вложенностью, insert'ы, update'ы и т.п. сложно назвать функциональным языком.
Да, кстати в IDEA есть возможность устанавливать условия срабатывания Breakpoint'ов. Поэтому вместо checkSize можно установить breakpoint с условием referenceSet.size() != size() и никаких assert'ов с разборами непонятных стек трейсов.
5) Не всякая система позволяет себя ронять и поднимать, иногда это будет обходится очень дорого (см. выше),

6) Логирования подозрительных кусков кода можно использовать на продакшене и на QA серверах, в отличии от assert'ов.

7) В современных IDE, вроде IDEA, достаточно способов отладки без всяких assert'ов, используя точки остановки c условиями. Причем в отличии от assert'ов, можно анализировать состояние реальных классов и переменных в живую, а не одного стек трейса.

8) Assert в целом не гарантирует правильность кода, так как он будет существовать максимум только у разработчика при отладки базовых сценариев, а вот в QA, при интеграционном и функциональном тестировании (и тем более на продакшене) он скорее всего будет отключен, то есть с большой вероятностью именно самые важные тесты он и не поймает, в отличии от правильно написанных тестов или правильного логирования.

9) В результате, правильное логирование, отладка и все возможные тесты и так покрывают большинство случаев где нужен assert,

10) В отличии от assert'ов логирование покажет сразу ВСЕ ошибки. Если в системе провалится несколько проверок, то логирование покажет их все, а assert потребует отладки каждой по отдельности. Ещё хуже если ошибки взаимосвязанные, есть большой шанс, что будешь разбираться со следствием, вместо причины, потому что тот assert сработал первым.
Такое логгирование ничем не лучше по производительности, потому что надо поддерживать то же самое проверлчное состояние и делать те же проверки

Кто мешает убрать все проверки сразу после отладки из реального кода?

за исключением того, что оно не будет падать, хотя, по-хорошему, должно

Кому должно падать? Я работал с системами, запуск, которых занимал до часа. Работал с системами, настолько большими. что физически не были способны работать иначе чем на сверхдорогом сервере, где сидела вся команда из пары десятков разработчиков. Отладка падениями обошлась бы там очень дорого.

Ещё раз assert'ы плохи тем что:
1) У QA и в системах непрерывного тестирования настройки могут быть как на продакшене, а значит никаких assert'ов работать не будет, если log.error легко поймать в логах автоматическими средствами, то assert'ы нет,

2) Если у QA или в системах непрерывного тестирования assert'ы включены, то с большим шансом тестирование может прерваться и QA заведут блокер с наивысшим приоритетом и не смогут тестировать релиз вообще. В результате даже пустячная проблема с assert'ов потребует сверх срочного решения. Ошибка в логах, приведет к созданию обычного тикета, который можно будет сделать в рабочем порядке.

3) Assert'ы мешают другим разработчикам,

4) Assert'ы нарушают разделение рабочего кода и кода тестирования, часто усложняя понимание кода
2) Вы описали странный случай, когда у вас две дублирующие логики в одном классе для проверки своего хранилища. Если вам так уж нужно было это отладить, ну добавили вы этот код, повесили точку останова на
private void checkSize() {
if(referenceSet.size() != size()) {
// точка остановки отладки
}
запустили отладку, а после того как нашли проблему убрали лишний код. Зачем тут assert'ы и лишний код, который никогда не будет работать в реальном приложении? В отличии от assert'а, в Idea можно будет анализировать код всех переменных и вызывать любые выражения, что позволит найти проблему намного быстрее. Вывод: совершенно непонятно, чем тут assert лучше обычного отладочного кода. Совершенно непонятно зачем в рабочем коде проекта отладочный мусор, да ещё и обработка AssertError'ов.

3) По умолчанию error'ы вообще не должны по-хорошему обрабатываться и выбрасываться. «An Error is a subclass of Throwable that indicates serious problems that a reasonable application should not try to catch. Most such errors are abnormal conditions.»

Информация

В рейтинге
2 475-й
Откуда
Luxemburg, Luxembourg, Люксембург
Дата рождения
Зарегистрирован
Активность