Скорее всего они бы и хотели, только вот наверняка не проводились учения при таких масштабных проблемах. Никто не тренировался с нуля поднимать весь сервис — а там сотни серверов, и не факт, что у них это было полностью автоматизировано.
Почитайте интересную статью про ОК, чтобы понимать масштаб: habr.com/ru/company/odnoklassniki/blog/268413
Кроме того, может и оригиналы видосов тоже потеряны, просто пока не говорят.
Я постоянно думаю о том, когда же начнут зубы клонировать! У вас есть какая-нибудь инфа по исследованиям в эту сторону? Хочется, чтобы в итоге стоматология сместилась в сторону замены зубов родными клонами, а не вот это вот все с удалением нервов, коронками, протезами.
А смысл кого-то наказывать? Обычно инцидент — это вина сразу нескольких человек\отделов: где-то плохо код написали, где-то плохо его проревьюили, где-то плохо протестировали.
Поэтому обычно пытаются подумать над тем, что привело к проблеме и как ее не допустить в будущем.
Например изменением регламентов или вводом новых инструментов.
А есть встроенный громкоговоритель, чтобы отгонять злоумышленников сиреной и угрозами расправы? :)
Мне кажется, как только история станет массовой — всякие пьяные школьники начнут нападать на роботов. Если даже самокаты умудряются вандалить.
работает не везде, где не работает можно оставить type=«password», т.к. только хром так навязчиво с паролями работает. Ну и в интернете есть полифилы на шрифтах.
Если мне не изменяет память, на одной из конференций они прямо говорили, что ничего особо не удаляют по техническим причинам, связанных с фрагментацией. Типа хранить проще, чем заниматься удалением. Звучит странно, конечно.
В современных браузерах кеш разделяется по доменам для того, чтобы нельзя было отследить, посещали ли вы другой сайт. Например, я могу разместить скрипт с уникальным названием на сайте А, и посмотреть, загружали ли вы этот ресурс при открытии сайта Б.
Вот об этом и речь :) Когда я смотрел исходники вашей orm, почему-то казалось, что вашим разработчикам отключили доступ в интернет. Окей, допустим есть какие-то причины не брать готовые решения, но ведь можно изучить готовые и сделать как минимум не хуже. Ведь все опенсорс решения прошли определенный путь, решили кучу проблем и обошли грабли. Писать с нуля orm без большого опыта с другими решениями — опрометчиво.
Я люблю велосипеды, но прежде чем писать свой — изучаю исходники других более-менее популярных решений и много нового для себя узнаю. В противном случае я бы это узнал уже в процессе эксплуатации своего велосипеда. В вашем же случае вообще нельзя допускать архитектурных ошибок, т.к. это юзерспейс, это будут использовать разработчики, все должно быть продумано на берегу.
Хорошо, можете с ходу сказать, как мне через вашу orm создать запрос с функцией JSON_CONTAINS?
В опенсорс решениях это давно все либо есть из коробки, либо можно удобно писать sqlRaw и выглядело бы это примерно так: ->andWhere(new Expression('JSON_CONTAINS(categories, 2'));
с вашей орм я чуть с ума не сошел, код показывать не буду. Либо документация неполная, либо действительно момент с rawSql не продуман.
Если даже популярное решение забросят, что маловероятно (Doctrine ORM?) его всегда можно форкнуть и развивать самостоятельно.
Насчет композера: кроме удобства управления пакетами у него есть очень важная штука — автолоадинг. Т.е. при обслуживании запроса приложение не заставляет интерпретатор все классы приложения интерпретировать и держать в памяти, а только те, что используются. Я конечно видел у вас штуку типа loadModule, но это все равно грубо, при запросе я так понимаю большая часть ядра грузиться в память.
Просто мне кажется, отворачиваться от сообщества не самая лучшая идея. Использование композера это не модно, это реально удобно и правильно. Вы можете в композер засовывать свои пакеты и ни от кого не зависеть. А популярные пакеты хорошо документированы и у многих есть опыт с ними.
Как успешный пример посмотрите на эту ПИМ+ЦМС систему pimcore.com/en
Она сейчас сильно набирает популярность, просто пока на западе. Посмотрите на их документацию, инструменты для деплоя из коробки.
У меня тогда провокационный вопрос, может Вы в курсе. Почему битрикс до сих пор хранит все файлы в document root? Можно же даже с обратной совместимостью сделать папку public и в ней один файл index.php с нормальным роутингом как у всех, а все остальное оставить выше. Тогда бы не было проблем с кучей htaccess и конфиг ngnix был бы неизменным. Это надо было сделать еще лет 10 назад, но может есть подвижки в эту сторону?
И еще вопрос: почему не используете решения сообщества, обкатанные всем миром, а пишете велосипеды. Т.е. место того, чтобы взять популярную ORM и на базе нее построить свое решение, сделали какую-то неюзабельную штуку на массивах. Как я понимаю, в битриксе вообще ни одного пакета, установленного через composer нет…
В общем ждем битрикс2.0 на симфони, иначе я не очень понимаю, как вы дальше будете развивать свой продукт.
Главное периодически делайте снимок на предмет наличия кисты, зуб может не болеть, если киста нерв сожрала. А кисту вылечить намного сложнее, можно и зуб потерять.
Тащить iframe все равно скорее всего придется для более-менее крупного виджета, чтобы на ваше приложение не влияли стили сайта, и чтобы сторонний сайт не имел доступ к DOM (там могут быть пользовательский данные).
В iframe нет ничего плохого, наоборот — дает хорошую изоляцию от чужого сайта. А postMessage решает все проблемы взаимодействия.
Обычно самые сложные части виджета отображаются во фрейме, а код генерирует только какую-нибудь кнопку, обертку или модалку. В таких случаях подключение целого фреймворка может быть перебором.
Ну и придется обеспечить изоляцию фреймворка или библиотеки, которую вы принесли, чтобы не сорить в глобальном пространстве и не влиять на сторонний сайт.
На мой взгляд с дивана заблокировать массовый спам довольно просто — оператору достаточно собирать статистику сколько делает звонков абонент и сколько из них заканчиваются через несколько секунд, когда адресат бросает трубку, услышав очередные услуги клиники или адвокатов.
А если вспомнить, что сейчас 2021 год, есть распознавание речи и все эти нейросети, и что уже давно можно автоматически определять, что абонент говорит всем одно и тоже — вообще проблемы никакой нет. Даже живой человек не нужен для поимки злостных спамщиков.
Основная проблема в том, что операторам пофиг на конечных пользователей (а еще спамеры платят за услуги), и пока их хорошенько не будут штрафовать за отсутствие контроля и пока штрафы не перевесят доходы — ничего не изменится. Либо пока это не станет конкурентным преимуществом :)
Почитайте интересную статью про ОК, чтобы понимать масштаб: habr.com/ru/company/odnoklassniki/blog/268413
Кроме того, может и оригиналы видосов тоже потеряны, просто пока не говорят.
Поэтому обычно пытаются подумать над тем, что привело к проблеме и как ее не допустить в будущем.
Например изменением регламентов или вводом новых инструментов.
Мне кажется, как только история станет массовой — всякие пьяные школьники начнут нападать на роботов. Если даже самокаты умудряются вандалить.
developer.mozilla.org/en-US/docs/Web/CSS/-webkit-text-security
работает не везде, где не работает можно оставить type=«password», т.к. только хром так навязчиво с паролями работает. Ну и в интернете есть полифилы на шрифтах.
Я у них недавно спрашивал здесь в комментах за композер, document root и прочее - сказали, что у них и так все хорошо
https://habr.com/ru/company/bitrix/blog/555232/#comment_22996426
Я люблю велосипеды, но прежде чем писать свой — изучаю исходники других более-менее популярных решений и много нового для себя узнаю. В противном случае я бы это узнал уже в процессе эксплуатации своего велосипеда. В вашем же случае вообще нельзя допускать архитектурных ошибок, т.к. это юзерспейс, это будут использовать разработчики, все должно быть продумано на берегу.
В опенсорс решениях это давно все либо есть из коробки, либо можно удобно писать sqlRaw и выглядело бы это примерно так:
->andWhere(new Expression('JSON_CONTAINS(categories, 2'));
с вашей орм я чуть с ума не сошел, код показывать не буду. Либо документация неполная, либо действительно момент с rawSql не продуман.
Насчет композера: кроме удобства управления пакетами у него есть очень важная штука — автолоадинг. Т.е. при обслуживании запроса приложение не заставляет интерпретатор все классы приложения интерпретировать и держать в памяти, а только те, что используются. Я конечно видел у вас штуку типа loadModule, но это все равно грубо, при запросе я так понимаю большая часть ядра грузиться в память.
Просто мне кажется, отворачиваться от сообщества не самая лучшая идея. Использование композера это не модно, это реально удобно и правильно. Вы можете в композер засовывать свои пакеты и ни от кого не зависеть. А популярные пакеты хорошо документированы и у многих есть опыт с ними.
Как успешный пример посмотрите на эту ПИМ+ЦМС систему pimcore.com/en
Она сейчас сильно набирает популярность, просто пока на западе. Посмотрите на их документацию, инструменты для деплоя из коробки.
И еще вопрос: почему не используете решения сообщества, обкатанные всем миром, а пишете велосипеды. Т.е. место того, чтобы взять популярную ORM и на базе нее построить свое решение, сделали какую-то неюзабельную штуку на массивах. Как я понимаю, в битриксе вообще ни одного пакета, установленного через composer нет…
В общем ждем битрикс2.0 на симфони, иначе я не очень понимаю, как вы дальше будете развивать свой продукт.
Часть умных мыслей по вашим вопросам хорошо описана в книге «Совершенный код» Макконнелл С.
В iframe нет ничего плохого, наоборот — дает хорошую изоляцию от чужого сайта. А postMessage решает все проблемы взаимодействия.
Ну и придется обеспечить изоляцию фреймворка или библиотеки, которую вы принесли, чтобы не сорить в глобальном пространстве и не влиять на сторонний сайт.
А если вспомнить, что сейчас 2021 год, есть распознавание речи и все эти нейросети, и что уже давно можно автоматически определять, что абонент говорит всем одно и тоже — вообще проблемы никакой нет. Даже живой человек не нужен для поимки злостных спамщиков.
Основная проблема в том, что операторам пофиг на конечных пользователей (а еще спамеры платят за услуги), и пока их хорошенько не будут штрафовать за отсутствие контроля и пока штрафы не перевесят доходы — ничего не изменится. Либо пока это не станет конкурентным преимуществом :)