Клевая штука, нужно обязательно заюзать у себя! Но так до конца и не понял:
В нашем случае это ограничения, накладываемые на структуру проекта
Вы парсите html файлы? Если да, тогда зачем что-то ограничивать, можно распарсить и выявить все зависимости по цепочке. Если нет, тогда почему не парсите? Можно какой-нибудь утилитой сначала составить список всех файлов в проекте, чтобы найти все html`ки.
Коротко об опыте: «нужен автоперевод». Для этого сделали велосипед: http://bakhirev.biz/demo/language/
Умеет переводить, преобразовывать в нужный формат, и самостоятельно сохранять в файлики (если запущен локально).
Прочитал статью, но не понял связи сайтов и производительности.
Если мы показываем информацию — производительность нам не нужна. Если мы работаем со звуком, видео или картинками в онлайн редакторе — то на старых устройствах все равно ничего работать не будет, т.к. нет соответствующего API.
Приведите пример связи сайта с производительности устройства.
довольно конкурентноспособный фреймворк для разработки мобильных приложений и игр,
Зачем мы пытаемся запихнуть JS в мобильник:
— Один код для offline и online игрушек. Кросплатформенность.
Что делает Tabris со своими шаблонами и компонентами? Он убивает нашу возможность переиспользования кода для десктопный версий.
Файл .apk приложения занимает порядка 10Мб — больше, чем голая Cordova (~2-3Мб), но меньше проекта с Chrome WebView (~19Мб)
Сколько должен весить готовый билд?
— Не более 5 мб, а для HTML приложения и двух более чем достаточно.
Это ограничение от заводов изготовителей на предустановленные приложения. Что делает Tabris? Он убивает эту возможность. Да и где вы, господа, видели голый WebView в 19 метров? Вот вам пример droidzoom.com/games/info.html?id=254 — всего 1.9 метра с кучей доп. фич внутри.
Давайте теперь анимируем каждый элемент нашей коллекции.
А давайте получим emei, mcc, mnc и попытаемся скрестить его с какой-нибудь SDK монетизации (https://fortumo.com/) или баннерной сетью (https://www.adfox.ru/). Мы сможем это сделать быстро и без боли? Насколько долго мобильному разработчику придется копаться в коде (с WebView это было очень легко и быстро)? Именно эти вопросы важны для тех, кто пихает JS в мобильники.
Библиотека проигрывает MIDI, при том «богомерзкий IE конечно в пролёте». Но богомерзкий IE мог проигрывать MIDI ещё в версии 3.0 от 1996 года. 96 КАРЛ!!! (они тогда еще всех достали, т.к. сайты начали ставить фоновую музыку)
Генерация звук задача редкая. А для игр важнее не генерировать, а одновременно проигрывать несколько mp3 и динамически изменять их громкость, в зависимости от расстояния до объектов. Ну а в общем, +1 за статью
Если ключи остались в localStorage — оно дешифруется. Если ключи были удаленны по какой-то причине, то уже никак. В этом и фишка. Есть возможность более менее гарантированно уничтожить написанное в соц. сети.
1. Исходники можно почитать, если установить плагин и открыть панель разработчика (F12) или посмотреть папку хрома, в которую он установится. Выкладывать на github смысла не вижу.
2. Про OTR не знал.
Никак. Эта атака нецелесообразна для сайтов соц. сетей. Проще достать с localStorage ключики, или угнать уже расшифрованный текст с интерфейса.
При любой атака и защите от неё нужно прежде всего рассматривать рентабельность. Маловероятно, что кто-то будет сильно замарачиватся с расширением, у которого 3.5 пользователя.
Но тут не про блоки. Тут длинный текст, который нужно зашифровать открытым ключом. Мне кажется логично, что библиотека должна получить текст и вернуть шифровку, и довольно странно, что она не хочет этого делать.
При том другая библиотека шифровала текст любой длины, но имела недостатки в других методах.
А что если собеседник будет использовать модифицированную версию плагина, которая не слушает команды и не удалаяет ключи? Что если собеседник записывает ключи из плагина?
Значит это не среднестатистическая девушка / пользователь. И, возможно, не стоит вообще писать ему лишнее.
Прочитав исходный код, я понял, что у автора нет понимания свойств RSA.
Можно более подробнее? RSA я не писал, а использовал чужую библиотеку. Если она плоха, можно ее заменить.
Вы парсите html файлы? Если да, тогда зачем что-то ограничивать, можно распарсить и выявить все зависимости по цепочке. Если нет, тогда почему не парсите? Можно какой-нибудь утилитой сначала составить список всех файлов в проекте, чтобы найти все html`ки.
Зачем он вам? Вы же не отдаете статику через ноду?
Можете примерно сказать нагрузку? У нас тоже есть такое, но начинают тормозить инстансы с говнокодом. За нормальными такого замечено не было.
Умеет переводить, преобразовывать в нужный формат, и самостоятельно сохранять в файлики (если запущен локально).
Если мы показываем информацию — производительность нам не нужна. Если мы работаем со звуком, видео или картинками в онлайн редакторе — то на старых устройствах все равно ничего работать не будет, т.к. нет соответствующего API.
Приведите пример связи сайта с производительности устройства.
Зачем мы пытаемся запихнуть JS в мобильник:
— Один код для offline и online игрушек. Кросплатформенность.
Что делает Tabris со своими шаблонами и компонентами? Он убивает нашу возможность переиспользования кода для десктопный версий.
Сколько должен весить готовый билд?
— Не более 5 мб, а для HTML приложения и двух более чем достаточно.
Это ограничение от заводов изготовителей на предустановленные приложения. Что делает Tabris? Он убивает эту возможность. Да и где вы, господа, видели голый WebView в 19 метров? Вот вам пример droidzoom.com/games/info.html?id=254 — всего 1.9 метра с кучей доп. фич внутри.
А давайте получим emei, mcc, mnc и попытаемся скрестить его с какой-нибудь SDK монетизации (https://fortumo.com/) или баннерной сетью (https://www.adfox.ru/). Мы сможем это сделать быстро и без боли? Насколько долго мобильному разработчику придется копаться в коде (с WebView это было очень легко и быстро)? Именно эти вопросы важны для тех, кто пихает JS в мобильники.
Генерация звук задача редкая. А для игр важнее не генерировать, а одновременно проигрывать несколько mp3 и динамически изменять их громкость, в зависимости от расстояния до объектов. Ну а в общем, +1 за статью
зы: таки да :3
Переходим, пишем ТЗ, заказываем.
2. Про OTR не знал.
При любой атака и защите от неё нужно прежде всего рассматривать рентабельность. Маловероятно, что кто-то будет сильно замарачиватся с расширением, у которого 3.5 пользователя.
Думаю через некоторое время заменю алгоритм шифрования на тот, который предложат комментаторы в ходе обсуждения.
Нет, на каждый диалог — свой приватный ключ
Если он сотрудник ФСБ, то знать ключи ему не обязательно. Переписку взломают с помощью терморектального криптоанализатора
При том другая библиотека шифровала текст любой длины, но имела недостатки в других методах.
Значит это не среднестатистическая девушка / пользователь. И, возможно, не стоит вообще писать ему лишнее.
Можно более подробнее? RSA я не писал, а использовал чужую библиотеку. Если она плоха, можно ее заменить.