Деньги действительно должны быть в относительной безопасности, но… есть нюансы.
Они должны были по закону храниться на отдельных счетах (т. н. ring-fenced; вроде даже не в самом Wirecard, а в Barclays, но это не точно) и не тратиться на инвестиции, кредитование, расходы и т. п. самого Wirecard. Обычно британский регулятор следит за исполнением этого очень рьяно (по российским меркам), поэтому в стандартном случае убыточного банка, которому, например, просто не дали новый раунд инвестиций и он обанкротился — всё четко.
Тут ситуацию осложняет то, что, насколько я понял, была подделана отчетность немецкого банка и организовалась дыра в упомянутые €1.9 млрд и вроде как немецкий регулятор, во-первых, в целом не уследил за этим, во-вторых, ходят слухи, что осведомитель (whistleblower) подавал соответствующую жалобу ещё весной и регулятор на неё не среагировал (возможно, там кто-то был в доле), не сообщил в криминальную полицию или что-то такое, как должен был. Если на блокировку Payoneer повлияли действия британского регулятора, то, наверное, его деньги ring-fenced в Британии и дыра у немецкого банка на них повлиять не должна.
Нужно понимать, что деньги не застрахованы. Эта безопасность — не аналог российского АСВ. Если вдруг откроется, что денег нет — государство, регулятор, специальный фонд, страховка не вступятся и не выплатят из общего котла. Будет стандартная процедура возмещения кредиторам в порядке очереди после реализации имущества банка (которого всем не хватит).
Вроде всё указывает на то, что те платежные системы, на блокировку которых повлияли действия британского, а не немецкого регулятора, должны быть в безопасности.
В любом случае есть мнение, что несмотря на то, что деньги в относительной безопасности, заблокированы они как минимум на недели, а возможно на месяцы. Так что если это ваши последние — наверное, следует срочно искать временные пути получения денег другим путём, не надеясь на разблокировку в течение дней.
В написанном на 100% не уверен, это моё представление после кратного расследования ввиду блокировки карты другой платежной системы, которой я активно пользовался, но на которой не хранил никакие деньги, поэтому досконально не разбирался. Тем не менее, надеюсь, кому-нибудь поможет. IMHO.
Я возможно не до конца понял, что вам надо, но в первую очередь в голову пришел следующий подход.
При добавлении товара всегда проставлять ему номер по порядку в рамках конкретного магазина. Это относительно дешево. В таблице магазинов держать максимальный номер по порядку для каждого магазина.
Кэшировать соответствие магазин — максимальный номер по порядку. Если магазинов не планируется в ближайшее время тысячи, то тоже относительно дешево. Поскольку изменения происходят редко, то консистентность кэша достаточно поддерживать просто протуханием через некоторое время — новый товар не будет отображаться лишь это время.
Выбрать генератор случайных чисел, у которого можно независимо от других его вызовов (условно, вроде mt_rand из PHP не подойдет) читать и писать состояние (сид фактически). Для первой страницы генерировать случайный сид и писать его в генератор. Для каждого магазина (ну или для нужного количества, если на странице надо показать меньше записей, чем всего магазинов) генерировать число от 1 до максимального номера по порядку этого магазина (см. кэш выше). После генерации достаточного количества прочитать состояние сида.
Построить индекс shop_id, index по таблице products. Сделать в неё запрос вида SELECT… FROM products WHERE (shop_id, index) IN((X1, I1), (X2, I2), ...), где Xn и In — идентификатор n-ого магазина и сгенерированный для него случайный номер по порядку. Запрос должен быть дешевым.
Вывести это на страницу. В ссылке на вторую страницу передать прочитанное состояние сида. На второй странице сидировать им, а не случайным.
Оставшаяся проблема: товары будут повторяться на последующих страницах, когда генератор будет создавать одно и то же случайное число на разных страницах.
Большое спасибо за хороший howto. Давно хотелось сделать нечто подобное, но как представлял, сколько бы манов пришлось перерыть (не админ по профессии), — всегда оставлял на потом и довольствовался soho роутером, который качественно выполняет только основную функцию — раздача интернета IPv4, а на другие его производительности и качества и широты доступного ПО не хватает. Признайтесь: вы реально это в один день сделали или это плод многодневной (многомесячной?) работы по улучшению домашнего сервера? :)
По теме: могли бы пролить больше света на «Security warning! Настраивайте файрволы правильно!»? Как? Можно ли с роутера хотя бы базово защититься, например, разрешить только соединения, инициированные компьютером за ним, но не входящие? Как я понимаю, для этого нужен conntrack? А он будет работать без NAT? Что еще следует сделать с самого роутера для защиты IPv6?
> Если приложение меня устраивает — я не ищу ему замены. Лучшее — враг хорошего. А если приложение меня не устраивает — я найду ему альтернативу, даже если оно рекламируется силами самого только ее производителя.
подняв своим поиском рейтинг одного из монополистов (скорее всего Гугла и/или Фейсбука, а может просто какого-нибудь популярного IT-новостного сайта)
> Более того, я напишу об этом во всех социальных сетях, в которых зарегистрирован, тем самым помогая этому приложению,
бесплатно сгенерировав контент для этих (скорее всего опять же фактически монополистов-) социальных сетей и для индексирующего их Гугла, чем сделаете в первую очередь сети и Гугл более монополистами, чем поможете приложению — максимум его просто Гугл или Фейсбук позже подороже купит, чем было бы без вашего «напишу»
но раз своим «напишу» вы помогли заодно Гуглу или Фейсбуку, то для них это подороже будет незначительно — их капитализация-то тоже от вашей помощи растёт
> и обязательно клацну по рекламе на сайте этого приложения, чтобы тот же Гугл заплатил этим разработчикам какую-то копейку.
немного добавлю: чтобы те же рекламодатели заплатили этому Гуглу какую-то серьезную сумму, чтобы тот же Гугл заплатил этим разработчикам какую-то копейку
стоит ли снова повторять, кому вы поможете больше — Гуглу или разработчикам?
> А вообще было бы отлично, чтобы компании тратили деньги не на патентные суды, а на инженеров, разрабатывающих те самые приложения.
Да, было бы замечательно.
> Согласитесь, что если бы вы писали на bash, вам бы не пришлось указывать на тонкости рекурсивного удаления директории или запуска другой программы и получения данных от нее, не так ли?
Согласитесь, что если бы вы писали на bash, вам бы пришлось указывать на тонкости выборки из БД, кэширования, объектной модели, существующего кода etc.
Curve.
Не хочется ни обнадеживать, ни наводить панику.
Деньги действительно должны быть в относительной безопасности, но… есть нюансы.
Они должны были по закону храниться на отдельных счетах (т. н. ring-fenced; вроде даже не в самом Wirecard, а в Barclays, но это не точно) и не тратиться на инвестиции, кредитование, расходы и т. п. самого Wirecard. Обычно британский регулятор следит за исполнением этого очень рьяно (по российским меркам), поэтому в стандартном случае убыточного банка, которому, например, просто не дали новый раунд инвестиций и он обанкротился — всё четко.
Тут ситуацию осложняет то, что, насколько я понял, была подделана отчетность немецкого банка и организовалась дыра в упомянутые €1.9 млрд и вроде как немецкий регулятор, во-первых, в целом не уследил за этим, во-вторых, ходят слухи, что осведомитель (whistleblower) подавал соответствующую жалобу ещё весной и регулятор на неё не среагировал (возможно, там кто-то был в доле), не сообщил в криминальную полицию или что-то такое, как должен был. Если на блокировку Payoneer повлияли действия британского регулятора, то, наверное, его деньги ring-fenced в Британии и дыра у немецкого банка на них повлиять не должна.
Нужно понимать, что деньги не застрахованы. Эта безопасность — не аналог российского АСВ. Если вдруг откроется, что денег нет — государство, регулятор, специальный фонд, страховка не вступятся и не выплатят из общего котла. Будет стандартная процедура возмещения кредиторам в порядке очереди после реализации имущества банка (которого всем не хватит).
Вроде всё указывает на то, что те платежные системы, на блокировку которых повлияли действия британского, а не немецкого регулятора, должны быть в безопасности.
В любом случае есть мнение, что несмотря на то, что деньги в относительной безопасности, заблокированы они как минимум на недели, а возможно на месяцы. Так что если это ваши последние — наверное, следует срочно искать временные пути получения денег другим путём, не надеясь на разблокировку в течение дней.
В написанном на 100% не уверен, это моё представление после кратного расследования ввиду блокировки карты другой платежной системы, которой я активно пользовался, но на которой не хранил никакие деньги, поэтому досконально не разбирался. Тем не менее, надеюсь, кому-нибудь поможет. IMHO.
Я правильно понимаю, что 20 федеральных каналов бесплатно транслировать вы перестали?
Я возможно не до конца понял, что вам надо, но в первую очередь в голову пришел следующий подход.
При добавлении товара всегда проставлять ему номер по порядку в рамках конкретного магазина. Это относительно дешево. В таблице магазинов держать максимальный номер по порядку для каждого магазина.
Кэшировать соответствие магазин — максимальный номер по порядку. Если магазинов не планируется в ближайшее время тысячи, то тоже относительно дешево. Поскольку изменения происходят редко, то консистентность кэша достаточно поддерживать просто протуханием через некоторое время — новый товар не будет отображаться лишь это время.
Выбрать генератор случайных чисел, у которого можно независимо от других его вызовов (условно, вроде mt_rand из PHP не подойдет) читать и писать состояние (сид фактически). Для первой страницы генерировать случайный сид и писать его в генератор. Для каждого магазина (ну или для нужного количества, если на странице надо показать меньше записей, чем всего магазинов) генерировать число от 1 до максимального номера по порядку этого магазина (см. кэш выше). После генерации достаточного количества прочитать состояние сида.
Построить индекс shop_id, index по таблице products. Сделать в неё запрос вида SELECT… FROM products WHERE (shop_id, index) IN((X1, I1), (X2, I2), ...), где Xn и In — идентификатор n-ого магазина и сгенерированный для него случайный номер по порядку. Запрос должен быть дешевым.
Вывести это на страницу. В ссылке на вторую страницу передать прочитанное состояние сида. На второй странице сидировать им, а не случайным.
Оставшаяся проблема: товары будут повторяться на последующих страницах, когда генератор будет создавать одно и то же случайное число на разных страницах.
Скорее всего есть решение проще.
Что-то обещают.
По теме: могли бы пролить больше света на «Security warning! Настраивайте файрволы правильно!»? Как? Можно ли с роутера хотя бы базово защититься, например, разрешить только соединения, инициированные компьютером за ним, но не входящие? Как я понимаю, для этого нужен conntrack? А он будет работать без NAT? Что еще следует сделать с самого роутера для защиты IPv6?
подняв своим поиском рейтинг одного из монополистов (скорее всего Гугла и/или Фейсбука, а может просто какого-нибудь популярного IT-новостного сайта)
> Более того, я напишу об этом во всех социальных сетях, в которых зарегистрирован, тем самым помогая этому приложению,
бесплатно сгенерировав контент для этих (скорее всего опять же фактически монополистов-) социальных сетей и для индексирующего их Гугла, чем сделаете в первую очередь сети и Гугл более монополистами, чем поможете приложению — максимум его просто Гугл или Фейсбук позже подороже купит, чем было бы без вашего «напишу»
но раз своим «напишу» вы помогли заодно Гуглу или Фейсбуку, то для них это подороже будет незначительно — их капитализация-то тоже от вашей помощи растёт
> и обязательно клацну по рекламе на сайте этого приложения, чтобы тот же Гугл заплатил этим разработчикам какую-то копейку.
немного добавлю: чтобы те же рекламодатели заплатили этому Гуглу какую-то серьезную сумму, чтобы тот же Гугл заплатил этим разработчикам какую-то копейку
стоит ли снова повторять, кому вы поможете больше — Гуглу или разработчикам?
> А вообще было бы отлично, чтобы компании тратили деньги не на патентные суды, а на инженеров, разрабатывающих те самые приложения.
Да, было бы замечательно.
Mac OS X \r
Остальной *nix \n
AFAIK
Согласитесь, что если бы вы писали на bash, вам бы пришлось указывать на тонкости выборки из БД, кэширования, объектной модели, существующего кода etc.