Конечно, позиция "моя хата с краю" всегда очень удобная. Ну и что, что там кого-то блокировали (причем я не говорю вообще ни про шаманов, ни про газманов). Те что нужны мне, не блокировали. И тут даже как бы и возразить нечего, просто придет время и ваш контент тоже заблокируют.
Но я обратил ваше внимание на то, что вот эта позиция провозглашается как призыв к свободе, равенству и братству. Информация должна быть свободной! (И я тоже с этим согласен) Но причем тут ютуб, где информация давно под контролем и там только та, что надо информация. А что не надо - не там.
Как говорится, вы или крестик снимите или штаны наденьте.
То есть, когда ютуб понижает ролик в выдаче, снимает монетизацию, выдает шадоубаны и блокирует каналы без особых объяснений, причем зачастую без возможности как-то объясниться - [this is fine.jpg].
Я бы сказал, тут не статья, а наглядное пособие о том как делать не надо.
Если я правильно понимаю, есть ряд независимых таблиц, которые друг с другом никак не связаны, но зачем-то их пытаются связать. Соответственно никаких ключей там скорее всего нет. Оператор UNION нам как бы подсказывает, что идет не выборка, а сборка. Если на это всё еще накладывать условия и сортировки - это заставит базу выбирать все строки, складывать их у себя в уме и преобразовывать результат. Уже можно тушить свет и вся надежда только на мощь базы и умность оптимизатора.
Дальше мы по потенциально ОЧЕНЬ большому количеству строк делаем BULK COLLECT (что правильно), но без LIMIT - ау, память бесконечная?
А в варианте решения потабличном наоборот не делаем BULK и обрабатываем построчно, ну правильно, скорость то нам зачем.
Что можно делать - это нужно вникать в конкретику, но например объединить данные в одну таблицу, а системам вместо таблиц подпихнуть обновляемые view которые будут писать в эту таблицу. Фильтруйте записи до UNION, анализируйте ваши запросы по плану, используйте хинты. Возможно вообще есть смысл ваши селекты делать во временную таблицу и работать уже с ней.
Но лучшее решение - позвать грамотного DBA который поможет и разобраться с вашим звпросом и грамотно спроектирует базу.
Как познавательно, а теперь открываем любой поисковик и вбиваем туда эти 3 веселых буквы. А потом пробуем построить логическую цепочку от названия методики у непосвященного человека. Мне лично всё равно, но если вы хотите продвигать эту методику, стоит подумать над названием еще раз.
Не видел, чтобы за это доплачивали. Но на ваш вопрос, есть ответ простой - выступать должны те, кто это умеет. Если вам нужно, чтобы это был "технарь", то есть и такие, которые умеют и рассказывать. И даже не интроверты.
Оказывается, недостаточно просто создать продукт или работать в какой-то фирме. Иногда продукт или фирму надо еще презентовать. На разных конференциях, выставках и прочих мероприятиях с большим числом любопытных глаз. И вот тут многие вспоминают, что они вообще-то интроверты и такое не про них. Ну а если надо?
Я больше ругаюсь вот на это вступление и стандартную фишку "менеджеров" сэкономить, типа ты же технарь, ты в курсе что там и как, вот возьми и расскажи. Ты же продукт только сделал, а теперь его еще и продать надо. Ага? Ну очень надо. Спс, родина тебя не забудет.
Упор не на сложность, а на не совсем уместную отсылку к интровертам + "бесплатную" работу не по специальности. И мой комментарий именно для того, чтобы сказать о том, что - это не ваша работа. Это ДРУГАЯ специализация. Вы можете, но НЕ ДОЛЖНЫ ей заниматься или обучаться. Поймите, "хрупкая девушка с маникюром" выйдет из борьбы с запаской с такими потерями для себя, причем с большой вероятностью безуспешно, что это вряд ли компенсирует ей что либо. А то везде риторика вида: ну а что такого - это же не сложно, вот я научился и делаю, почему ты не делаешь?
Нет, у вас не колесо пробило. А, скажем, вылетела пара предохранителей. Механики тоже разные по уровню бывают. В данном конкретном случае, вы из айтишника пытаетесь сделать еще и "актера". И как бы можно говорить, ну что такого, видите, питания нет, проверили предохранители, заменили за 10 минут и едете дальше. И этому не сложно научиться. Но..
Ну и даже если взять "колесо". А вы хрупкая женщина, на каблуках с маникюром и едете на ужин в вечернем платье. Ага? То что просто для кого-то, не значит просто для всех. Для интроверта выступление перед публикой на 20 человек - уже событие, и не важно насколько хорошо он знает предметную область и теорию выступлений. И лайфхаки типа "запаски", "домкрата" и "ключа в багажнике" выглядят в данном случае издевательством.
Да, есть водители, которые механики и умеют чинить свой автомобиль при поломках разного уровня сложности, но это такой же дополнительный скилл которому нужно учиться и который не каждому легко дается.
Не очень удачные примеры, лучше было бы рассмотреть какой-нить реальный кейс и ооп/функциональные варианты решений. У вас же получился пример конвертирования ооп в функциональные рамки, причем без особой на это надобности, при этом вы замаскировали исключение, а не обработали его. Конечно, иногда это может быть требованием задачи, но чаще является ошибкой и примером того, как не нужно писать код.
Опять же, исключения выбрасываются не для маскировки, а для обработки. И обрабатывать их нужно на том уровне, где это имеет смысл. Если вы не знаете, что делать с исключением, то вы просто отдаете его дальше, там разберутся. Но что делать в ваших функциональных примерах? Мы ожидали значение, а получили empty. Что произошло? Как на это реагировать? Зачем писать код таким образом? Какую конструкцию для корректной обработки придумать? Есть ли хороший паттерн для таких случаев?
Конечно, ваш подход вполне применим, но вы не смогли убедительно показать где и как его можно и нужно правильно использовать. Попробуйте взять реальную задачу(проблему), которую вы решали и показать как удобно её можно решить вашим способом, думаю так статья станет лучше.
Мм, мне казалось это очевидным. Давайте поясню. Чем больше у вас информации об объекте атаки, тем проще её провести. Например можно повысить уровень доверия для мошеннического звонка - "Алло, здравствуйте Иван Иванович, на вашем счёте столько-то денег, а вы знаете ....". "Иван Иванович, мы взломали ваш телефон и слили все ваши фотки, а еще записали с камеры телефона разные интересные видео. Чтобы вы не сомневались, баланс вашего телефона 525р. Если вы не переведете нам биткоинов <инструкция>, мы всё это разошлем в ваши контакты и соц.сети".
Можно повысить аккуратность всяких зловредов или зло-подписок, чтобы оставляли пару копеек на счёте, и пользователь замечал, что что-то пошло не так, не сразу после снятия денег, а в конце расчетного периода.
Ну и мало ли что еще придумают, чем больше приватной информации известно, тем больше вариаций можно придумать.
Всему тексту не хватает одной маленькой, но важной детали - описания постановки задачи. Знаете, как учат школьников. Дано, требуется найти, решение. Без этой детали, возникает желание докопаться до каждого пункта предложенного решения.
Так же плохи, зачастую никто же не беспокоится о безопасном хранении ответов? Это же не пароль?
Тут просто нужно понимать, что есть проблема "забывания паролей". Нужно как-то уметь их сбрасывать. Для этого нужно как-то валидировать инициатора сброса, когда у нас нет никаких персональных данных, мы должны их эмулировать. Вот тут и были придуманы вопросы. И когда вы используете их правильно, а именно: давая пользователю ввести свой вариант вопроса, храня ответы так же как пароли, безопасно и в виде хеша; ограничивая возможность перебора, N попыток и велком в саппорт; а самое главное - используя этот способ, только когда у вас нет никаких других вариантов установить подлинность владельца аккаунта. Ну или, если это просто еще один "заборчик" для доп.защиты в многоуровневой проверке (например как "кодовое слово" в банках).
Тут нужно понимать, что проблема не столько в методах, сколько в том где и как их реализуют и используют.
Я же ссылку оставил, можете сами попробовать. Тут же не "взлом" какой-то формы, а её штатное поведение, как в примере с аутентификацией по адресу электронной почты кто-то подумал, давайте пользователю сообщать, что у него денег на счёте недостаточно для перевода, чтобы он не получал отказ в транзакции после ввода кода из смс. Удобно же? Ну а то, что сервис не требует аутентификации и номер можно вбить любой, мелочи же? =) Да и кому он нужен, ваш баланс, да? =)
Откуда - вводите номер абонента мегафона, Куда - любой другой номер, а дальше в сумме подбираете циферки, пока не перестанет писать "недостаточно средств на счёте".
Ну вот, видите, оказывается не только школьник не понимает. Задача школьника - получение знаний, "инструмент" - это не тот скриптик для обхода тестов с дз, а сама платформа с дз, которая дает возможность школьнику получить знания и ему же проверить, насколько успешно он их усвоил (дз). И никому, кроме самого школьника это не нужно. Ровно поэтому тут не нужна какая-то защита для обхода проверки дз, это просто инструмент, который помогает школьнику, а не средство борьбы с ним.
Всё что реально надо было сделать - это объяснить ему эти простые факты и мотивировать его на получение знаний. Да, это может быть непростой задачей, особенно, если ей начать заниматься не с начальных этапов обучения, но и с подростком можно и нужно работать. А эффективность учёбы "из под палки", крайне низкая.
А то, о чём вы пишете "безопасность", "реклама", "фокус на возможностях" - это всё не про то, и не про там. Банковскому приложению нужна защита, системе тестирования школьников (все эти гос.экзамены и пр.) нужна защита, потому что это как раз те точки, где тесты нужны не школьнику, а системе образования (государству, бизнесу). А инструментам обучения не нужна защита от школьника, как скальпелю не нужно быть безопасным - ему нужно просто быть удобным инструментом для хирурга.
И я вполне понимаю школьника, он ребёнок, его "заставляют". Но не понимаю вас.
Проблема в том, что школьник так и не понял в чём у него проблема и очень печально, что ему это так и не объяснили. Эксплойты и т.п. - это все забавно, но ломать собственный же инструмент всё же не самая лучшая идея. А создавать "антивандальный" инструмент - контрпродуктивно.
Мы ознакомились с нумерованным списком ряда программ, отсортированных как придется и прочитали их описание как попало. Почему мы это сделали - неизвестно. Зачем - непонятно. Зато есть статья. Или это доклад семиклассника по информатике?
Конечно, позиция "моя хата с краю" всегда очень удобная. Ну и что, что там кого-то блокировали (причем я не говорю вообще ни про шаманов, ни про газманов). Те что нужны мне, не блокировали. И тут даже как бы и возразить нечего, просто придет время и ваш контент тоже заблокируют.
Но я обратил ваше внимание на то, что вот эта позиция провозглашается как призыв к свободе, равенству и братству. Информация должна быть свободной! (И я тоже с этим согласен) Но причем тут ютуб, где информация давно под контролем и там только та, что надо информация. А что не надо - не там.
Как говорится, вы или крестик снимите или штаны наденьте.
То есть, когда ютуб понижает ролик в выдаче, снимает монетизацию, выдает шадоубаны и блокирует каналы без особых объяснений, причем зачастую без возможности как-то объясниться - [this is fine.jpg].
А когда прищемили ютуб, то ой, а нас то за что?
Ура! За свободу! За профсоюз! :D
Я бы сказал, тут не статья, а наглядное пособие о том как делать не надо.
Если я правильно понимаю, есть ряд независимых таблиц, которые друг с другом никак не связаны, но зачем-то их пытаются связать. Соответственно никаких ключей там скорее всего нет. Оператор UNION нам как бы подсказывает, что идет не выборка, а сборка. Если на это всё еще накладывать условия и сортировки - это заставит базу выбирать все строки, складывать их у себя в уме и преобразовывать результат. Уже можно тушить свет и вся надежда только на мощь базы и умность оптимизатора.
Дальше мы по потенциально ОЧЕНЬ большому количеству строк делаем BULK COLLECT (что правильно), но без LIMIT - ау, память бесконечная?
А в варианте решения потабличном наоборот не делаем BULK и обрабатываем построчно, ну правильно, скорость то нам зачем.
Что можно делать - это нужно вникать в конкретику, но например объединить данные в одну таблицу, а системам вместо таблиц подпихнуть обновляемые view которые будут писать в эту таблицу. Фильтруйте записи до UNION, анализируйте ваши запросы по плану, используйте хинты.
Возможно вообще есть смысл ваши селекты делать во временную таблицу и работать уже с ней.
Но лучшее решение - позвать грамотного DBA который поможет и разобраться с вашим звпросом и грамотно спроектирует базу.
У вас же все дц в России. Hetzner в основном выбирается именно из-за локации дц.
Ну и да, цены у вас на виртуальные нарезки прям супер-элитные.
Как познавательно, а теперь открываем любой поисковик и вбиваем туда эти 3 веселых буквы. А потом пробуем построить логическую цепочку от названия методики у непосвященного человека. Мне лично всё равно, но если вы хотите продвигать эту методику, стоит подумать над названием еще раз.
ОКР - это к психотерапевту, использовать общеупотребимые акронимы в других смыслах будет вредить пониманию.
Не видел, чтобы за это доплачивали. Но на ваш вопрос, есть ответ простой - выступать должны те, кто это умеет. Если вам нужно, чтобы это был "технарь", то есть и такие, которые умеют и рассказывать. И даже не интроверты.
Оказывается, недостаточно просто создать продукт или работать в какой-то фирме. Иногда продукт или фирму надо еще презентовать. На разных конференциях, выставках и прочих мероприятиях с большим числом любопытных глаз. И вот тут многие вспоминают, что они вообще-то интроверты и такое не про них. Ну а если надо?Я больше ругаюсь вот на это вступление и стандартную фишку "менеджеров" сэкономить, типа ты же технарь, ты в курсе что там и как, вот возьми и расскажи. Ты же продукт только сделал, а теперь его еще и продать надо. Ага? Ну очень надо. Спс, родина тебя не забудет.
Упор не на сложность, а на не совсем уместную отсылку к интровертам + "бесплатную" работу не по специальности. И мой комментарий именно для того, чтобы сказать о том, что - это не ваша работа. Это ДРУГАЯ специализация. Вы можете, но НЕ ДОЛЖНЫ ей заниматься или обучаться. Поймите, "хрупкая девушка с маникюром" выйдет из борьбы с запаской с такими потерями для себя, причем с большой вероятностью безуспешно, что это вряд ли компенсирует ей что либо. А то везде риторика вида: ну а что такого - это же не сложно, вот я научился и делаю, почему ты не делаешь?
Нет, у вас не колесо пробило. А, скажем, вылетела пара предохранителей. Механики тоже разные по уровню бывают. В данном конкретном случае, вы из айтишника пытаетесь сделать еще и "актера". И как бы можно говорить, ну что такого, видите, питания нет, проверили предохранители, заменили за 10 минут и едете дальше. И этому не сложно научиться. Но..
Ну и даже если взять "колесо". А вы хрупкая женщина, на каблуках с маникюром и едете на ужин в вечернем платье. Ага? То что просто для кого-то, не значит просто для всех. Для интроверта выступление перед публикой на 20 человек - уже событие, и не важно насколько хорошо он знает предметную область и теорию выступлений. И лайфхаки типа "запаски", "домкрата" и "ключа в багажнике" выглядят в данном случае издевательством.
Да, есть водители, которые механики и умеют чинить свой автомобиль при поломках разного уровня сложности, но это такой же дополнительный скилл которому нужно учиться и который не каждому легко дается.
Это когда ты едешь на машине, и она вдруг ломается. Ты внезапно понимаешь, что ты не механик. Ну а если надо? Ну и скилл полезный, ага?
Не очень удачные примеры, лучше было бы рассмотреть какой-нить реальный кейс и ооп/функциональные варианты решений. У вас же получился пример конвертирования ооп в функциональные рамки, причем без особой на это надобности, при этом вы замаскировали исключение, а не обработали его. Конечно, иногда это может быть требованием задачи, но чаще является ошибкой и примером того, как не нужно писать код.
Опять же, исключения выбрасываются не для маскировки, а для обработки. И обрабатывать их нужно на том уровне, где это имеет смысл. Если вы не знаете, что делать с исключением, то вы просто отдаете его дальше, там разберутся. Но что делать в ваших функциональных примерах? Мы ожидали значение, а получили empty. Что произошло? Как на это реагировать? Зачем писать код таким образом? Какую конструкцию для корректной обработки придумать? Есть ли хороший паттерн для таких случаев?
Конечно, ваш подход вполне применим, но вы не смогли убедительно показать где и как его можно и нужно правильно использовать. Попробуйте взять реальную задачу(проблему), которую вы решали и показать как удобно её можно решить вашим способом, думаю так статья станет лучше.
Мм, мне казалось это очевидным. Давайте поясню. Чем больше у вас информации об объекте атаки, тем проще её провести. Например можно повысить уровень доверия для мошеннического звонка - "Алло, здравствуйте Иван Иванович, на вашем счёте столько-то денег, а вы знаете ....".
"Иван Иванович, мы взломали ваш телефон и слили все ваши фотки, а еще записали с камеры телефона разные интересные видео. Чтобы вы не сомневались, баланс вашего телефона 525р. Если вы не переведете нам биткоинов <инструкция>, мы всё это разошлем в ваши контакты и соц.сети".
Можно повысить аккуратность всяких зловредов или зло-подписок, чтобы оставляли пару копеек на счёте, и пользователь замечал, что что-то пошло не так, не сразу после снятия денег, а в конце расчетного периода.
Ну и мало ли что еще придумают, чем больше приватной информации известно, тем больше вариаций можно придумать.
Всему тексту не хватает одной маленькой, но важной детали - описания постановки задачи. Знаете, как учат школьников. Дано, требуется найти, решение. Без этой детали, возникает желание докопаться до каждого пункта предложенного решения.
Так же плохи, зачастую никто же не беспокоится о безопасном хранении ответов? Это же не пароль?
Тут просто нужно понимать, что есть проблема "забывания паролей". Нужно как-то уметь их сбрасывать. Для этого нужно как-то валидировать инициатора сброса, когда у нас нет никаких персональных данных, мы должны их эмулировать. Вот тут и были придуманы вопросы. И когда вы используете их правильно, а именно: давая пользователю ввести свой вариант вопроса, храня ответы так же как пароли, безопасно и в виде хеша; ограничивая возможность перебора, N попыток и велком в саппорт; а самое главное - используя этот способ, только когда у вас нет никаких других вариантов установить подлинность владельца аккаунта. Ну или, если это просто еще один "заборчик" для доп.защиты в многоуровневой проверке (например как "кодовое слово" в банках).
Тут нужно понимать, что проблема не столько в методах, сколько в том где и как их реализуют и используют.
Я же ссылку оставил, можете сами попробовать. Тут же не "взлом" какой-то формы, а её штатное поведение, как в примере с аутентификацией по адресу электронной почты кто-то подумал, давайте пользователю сообщать, что у него денег на счёте недостаточно для перевода, чтобы он не получал отказ в транзакции после ввода кода из смс. Удобно же? Ну а то, что сервис не требует аутентификации и номер можно вбить любой, мелочи же? =) Да и кому он нужен, ваш баланс, да? =)
Уже давно обнаружил и сообщил мегафону о небольшом их сервисе, который позволяет легко проверить баланс любого абонента мегафона по номеру телефона:
https://money.megafon.ru/money-transfers/mobile-to-mobile
Откуда - вводите номер абонента мегафона, Куда - любой другой номер, а дальше в сумме подбираете циферки, пока не перестанет писать "недостаточно средств на счёте".
Мегафон на моё сообщение пожал плечами и забил.
И вы тоже не поняли, чуть выше пояснил, надеюсь понятнее.
Ну вот, видите, оказывается не только школьник не понимает. Задача школьника - получение знаний, "инструмент" - это не тот скриптик для обхода тестов с дз, а сама платформа с дз, которая дает возможность школьнику получить знания и ему же проверить, насколько успешно он их усвоил (дз). И никому, кроме самого школьника это не нужно. Ровно поэтому тут не нужна какая-то защита для обхода проверки дз, это просто инструмент, который помогает школьнику, а не средство борьбы с ним.
Всё что реально надо было сделать - это объяснить ему эти простые факты и мотивировать его на получение знаний. Да, это может быть непростой задачей, особенно, если ей начать заниматься не с начальных этапов обучения, но и с подростком можно и нужно работать. А эффективность учёбы "из под палки", крайне низкая.
А то, о чём вы пишете "безопасность", "реклама", "фокус на возможностях" - это всё не про то, и не про там. Банковскому приложению нужна защита, системе тестирования школьников (все эти гос.экзамены и пр.) нужна защита, потому что это как раз те точки, где тесты нужны не школьнику, а системе образования (государству, бизнесу). А инструментам обучения не нужна защита от школьника, как скальпелю не нужно быть безопасным - ему нужно просто быть удобным инструментом для хирурга.
И я вполне понимаю школьника, он ребёнок, его "заставляют". Но не понимаю вас.
Проблема в том, что школьник так и не понял в чём у него проблема и очень печально, что ему это так и не объяснили. Эксплойты и т.п. - это все забавно, но ломать собственный же инструмент всё же не самая лучшая идея. А создавать "антивандальный" инструмент - контрпродуктивно.
Мы ознакомились с нумерованным списком ряда программ, отсортированных как придется и прочитали их описание как попало. Почему мы это сделали - неизвестно. Зачем - непонятно. Зато есть статья. Или это доклад семиклассника по информатике?