Вкратце: любые приватные данные, передаваемые через cloudflare (например, залогиненным пользователям), могли утечь другим людям, а так же остаться в любом кэше (гугла, интернет архива, других поисковиков). И да, они там действительно были найдены. И сейчас нет никакой возможности отследить, какие данные утекли. И я далеко не уверен, что кто-то не нашёл это раньше и не собирал это всё втихую.
И нет, пострадали не только те сайты, которые использовали «three minor Cloudflare features», пострадали остальные, а в те встраивалось содержимое других сайтов.
Можно вопрос, а почему вы решили идти по такому сложному пути, а не решились просто сделать кастомный адаптер и LayoutManager для того же RecyclerView? Это скорее всего решило бы ваши проблемы, так и дало бы больше гибкости.
240 минут в месяц на команду из 3.5 разработчиков хватало впритык, точно помню что приходилось что-то оптимизировать в билд-процессах. Если кроме билда есть еще и Deploy (Publish) — придется позаморачиваться с аргументами build-steps, неважно какой вы используете. Тесты нормально работают для MS тестов, если используется nUnit 3 часть отчетов придется просматривать руками, красивой картинки не будет (хотя лично мне хватает лога консоли). Некоторые типы проектов приходится билдить через msbuild.exe, кое-что берет только devenv.exe (это вызов cmd\ps команды с парой-тройкой аргументов). Интеграция с гитом минимальная, гораздо хуже чем с проектами tfs.
Короче, недостатков хватает. С другой стороны, работать можно, для «старой гвардии» и просто любознательных есть возможность пилить свои билд шаги (это по сути PS-скипты). Думаю, серьезный DevOps за неделю-две привыкнет.
Мы решили эту проблему путем сохранения Workflow сервисов в базе, то есть их версионирования. При изменении Workflow, добавляется его новая версия. Существующие экземпляры Workflow используют свои версии Workflow сервиса, а все новые экземпляры используют последнюю версию.
Позже напишу пример реализации подобного сценария.
в workflow foundation есть серъёзный недостаток, если используете persistence и у вас имеются workflow instances сохраненные на полпути и в workflow были внесены изменения, foundation не сможет эти изменениямкорректно обработать и instances становятся не валидными.
В общем — ситуацию надо было спасать. Засучив рукава, мы начали с чистого листа искать решение.
Молодцы, что решение всё таки нашли. Но так как статья с меткой «tutorial», то стоит отметить, что в mysql для таких целей уже есть всё необходимое (youlose уже упоминал это). Достаточно добавить в my.cnf несколько строчек:
В файл /var/log/mysql/slow.log будут попадать запросы которые выполняются медленнее 1 секунды, а так же запросы которые не используют индексы. Кроме самих запросов там много сопутствующей информации. В mariaDB или percona информации даже больше будет
Проблема читов в CS:GO реально есть, причем очень большая. И чем выше ранг, тем больше «мамкиных нагибаторов» в официальном матчмейкинге. Вообще, читеров можно разделить на две категории: которые начинают игру с читами и которые подрубают уже по ходу игры. Много раз видел, как бесполезные в перестрелке на AWP парни внезапно начинали давать такие префаеры, что сам KennyS обзавидуется.
Но при этом играть против читера реально, потому что:
1. в 99% их 1-2 человека.
2. Инфу на команду они дают только в 30-40% случаев (касается ВХ).
Играя против читера в голове стоит держать, что любые ваши самые хитрые перемещения на шифте известны команде противника. Как только вы это осознаете, играть становится проще. Если персональный скилл каждого участника команды позволяет нормально держать точки и перемещаться за КТ, то есть шансы выиграть на «чистом» скилле, уничтожая команду противника, а читера разменивая 1 в 2 или 1 в 3. Против ВХшников, по моим ощущениям, эффективно играть в несколько AWP. Это дает дистанцию и, если руки из плеч, гарантированный минус в команде противника, прежде чем авапер примет Ислам. Самое главное — чтобы в ВАШЕЙ команде не было истеричек-руинеров. Потому что против читеров сложнее играть в защите, когда они могут организовать атаку превосходящими силами. В атаке же всегда есть вариант взять пару AWP на команду и устроить размены, вне зависимости от карты (чуть сложнее на Mirage, т.к. из снайперских дистанций там только mid, проще на Nuke, train, dust2 и даже inferno).
Главное не забывать, что играешь с криворукой мразотой с подрубом, т.е. всегда помнить, что если ты достаешь флешку — то на тебя выходят. Если делаешь перезарядку — на тебя выходят. Если пушишь в смок — тебе дают префом по голове. В итоге: никаких смоков против читера, раскидка только из безопасных позиций (а не в упоре), релоад только после фрага-двух, а не во время перестрелки.
Если читер совсем дурак и играет на АВП, то его проще давить мясом. Конечно, кто-то умирает, но остальные проходят на позицию и мамкиного нагибатора наказывают.
Короче, при игре против читаков реально выигрывать при должном уровне коллективизма, аима и крепких неров. Потому что 1 в 3-5, если это не рейдж-спинбот, они не тащат. А если уж подрубили спин, то ничего с этим не сделать.
Как человек который занимался реверсом FairFight могу сказать что в том же BF4 и BF1 эта система банит лишь тру нагибаторов которые выносят все живое вроде 100% аим на хед и прочее, в других игр с FF ситуация примерно такая же.
То что Valve хотят это добавить приведет лишь к большему бану Легит игроков, т.е. превышение средних показателей = бан. Также как и баны CS:GO Overwatch (Патруль) — часто высосаны из пальца, если игрок играет хорошо и легит — но ему все равно пишут что он читер.
Когда наконец крупные разработчики игр не поймут — что пока античит не будет прозрачным, они эту проблему не решат. Самый идеальный вариант работы это когда все этапы хорошо видны — игрок получил N репортов на основании таких то моментов, после этого N = 100 игроков посмотрели и дали свое решение, дальше M = 20 игроков сделали свои оценки, после уходит C = 5 работникам античит отдела компании — в зависимости от весовой доли принимается решение, легит или нет. В том же CS:GO сейчас этого нету, там решение из Патруля прилетают напрямую, и значение N там может быть на уровне < 10, что по сути даже в мат. погрешность не укладывается.
https://github.com/pirate/sites-using-cloudflare
Вы недооцениваете масштабы проблемы.
Вкратце: любые приватные данные, передаваемые через cloudflare (например, залогиненным пользователям), могли утечь другим людям, а так же остаться в любом кэше (гугла, интернет архива, других поисковиков). И да, они там действительно были найдены. И сейчас нет никакой возможности отследить, какие данные утекли. И я далеко не уверен, что кто-то не нашёл это раньше и не собирал это всё втихую.
И нет, пострадали не только те сайты, которые использовали «three minor Cloudflare features», пострадали остальные, а в те встраивалось содержимое других сайтов.
Это полная задница, если честно.
240 минут в месяц на команду из 3.5 разработчиков хватало впритык, точно помню что приходилось что-то оптимизировать в билд-процессах. Если кроме билда есть еще и Deploy (Publish) — придется позаморачиваться с аргументами build-steps, неважно какой вы используете. Тесты нормально работают для MS тестов, если используется nUnit 3 часть отчетов придется просматривать руками, красивой картинки не будет (хотя лично мне хватает лога консоли). Некоторые типы проектов приходится билдить через msbuild.exe, кое-что берет только devenv.exe (это вызов cmd\ps команды с парой-тройкой аргументов). Интеграция с гитом минимальная, гораздо хуже чем с проектами tfs.
Короче, недостатков хватает. С другой стороны, работать можно, для «старой гвардии» и просто любознательных есть возможность пилить свои билд шаги (это по сути PS-скипты). Думаю, серьезный DevOps за неделю-две привыкнет.
XUL же мозилловцы вроде сами же и закопали после осознания его ненужности, нет?
Есть мнение что помещать в
.gitignoreтоже моветон) Нужно в.git/info/exclude. Но это конечно спорно~/.gitconfig
~/.gitexclude
Позже напишу пример реализации подобного сценария.
А потом они открыли для себя ssd диски, MariaDB и slow-query-log...
В файл /var/log/mysql/slow.log будут попадать запросы которые выполняются медленнее 1 секунды, а так же запросы которые не используют индексы. Кроме самих запросов там много сопутствующей информации. В mariaDB или percona информации даже больше будет
Но при этом играть против читера реально, потому что:
1. в 99% их 1-2 человека.
2. Инфу на команду они дают только в 30-40% случаев (касается ВХ).
Играя против читера в голове стоит держать, что любые ваши самые хитрые перемещения на шифте известны команде противника. Как только вы это осознаете, играть становится проще. Если персональный скилл каждого участника команды позволяет нормально держать точки и перемещаться за КТ, то есть шансы выиграть на «чистом» скилле, уничтожая команду противника, а читера разменивая 1 в 2 или 1 в 3. Против ВХшников, по моим ощущениям, эффективно играть в несколько AWP. Это дает дистанцию и, если руки из плеч, гарантированный минус в команде противника, прежде чем авапер примет Ислам. Самое главное — чтобы в ВАШЕЙ команде не было истеричек-руинеров. Потому что против читеров сложнее играть в защите, когда они могут организовать атаку превосходящими силами. В атаке же всегда есть вариант взять пару AWP на команду и устроить размены, вне зависимости от карты (чуть сложнее на Mirage, т.к. из снайперских дистанций там только mid, проще на Nuke, train, dust2 и даже inferno).
Главное не забывать, что играешь с криворукой мразотой с подрубом, т.е. всегда помнить, что если ты достаешь флешку — то на тебя выходят. Если делаешь перезарядку — на тебя выходят. Если пушишь в смок — тебе дают префом по голове. В итоге: никаких смоков против читера, раскидка только из безопасных позиций (а не в упоре), релоад только после фрага-двух, а не во время перестрелки.
Если читер совсем дурак и играет на АВП, то его проще давить мясом. Конечно, кто-то умирает, но остальные проходят на позицию и мамкиного нагибатора наказывают.
Короче, при игре против читаков реально выигрывать при должном уровне коллективизма, аима и крепких неров. Потому что 1 в 3-5, если это не рейдж-спинбот, они не тащат. А если уж подрубили спин, то ничего с этим не сделать.
То что Valve хотят это добавить приведет лишь к большему бану Легит игроков, т.е. превышение средних показателей = бан. Также как и баны CS:GO Overwatch (Патруль) — часто высосаны из пальца, если игрок играет хорошо и легит — но ему все равно пишут что он читер.
Когда наконец крупные разработчики игр не поймут — что пока античит не будет прозрачным, они эту проблему не решат. Самый идеальный вариант работы это когда все этапы хорошо видны — игрок получил N репортов на основании таких то моментов, после этого N = 100 игроков посмотрели и дали свое решение, дальше M = 20 игроков сделали свои оценки, после уходит C = 5 работникам античит отдела компании — в зависимости от весовой доли принимается решение, легит или нет. В том же CS:GO сейчас этого нету, там решение из Патруля прилетают напрямую, и значение N там может быть на уровне < 10, что по сути даже в мат. погрешность не укладывается.