Как стать автором
Обновить
18
0

Пользователь

Отправить сообщение

А, я подумал что написать адаптер который позволит вызывать как моем финальном варианте.
Да, тот вариант что вы предлагаете действительно прост в исполнении, но все равно я предпочту свой интерфейс. (плюс я не доволен кодом и сложностью lodash)

Справедливости ради, эта библиотека решает больше вопросов чем просто сортировка :)

Там проблемы не только в самом интерфейсе, но и в строгости. Этот функционал в lodash просто отсуствует.
Даже если вопрос был исключительно в удобности интерфейса, написать с нуля будет проще, чем писать такой адаптер.

Спасибо, такой подход это один из вариантов который я рассматривал, и правда можно довольно выразительно это сделать.


Но есть несколько замечаний:


  • сравнение чисел через compare_numb можно делать через compare_string и не обрабатывает NaN.
  • использование строк как ключей объектов не позволяет использовать TypeScript и более сложные выражения
  • я намеренно стремлюсь использовать сортировку именно по ключу, потому что это более очевидно для использования
  • бинарный поиск так же можно использовать, имея функцию ключа
Большое спасибо, исправлено!
Совершенно верно, и библиотека thenby использует именно этот подход.
Да, я уже говорил, что я читал научные статьи про математическую обфускацию.
Основная проблема, которую я вижу — есть классы функций, которые нельзя безопасно обфусцировать,
и есть *некоторые* функции, для которых придумали обфускацию. Этих функций очень мало, они «скучные» или их роль может выполнить другим путем.

> обфускация ПО для противодействия поиска уязвимости по патчу

Я вижу две проблемы:
— мне дается код, который я не должен понимать и он должен предоставить мне «безопасность». Security though obscurity.
— для детектирования «атаки» может понадобиться такая функция, которую невозможно безопасно обфусцировать.

> маркировка ПО.

Зачем?

> Существование универсальной обфускации в терминах определения чёрного ящика дало бы нам полную защиту ПО от обратной разработки.

Это *совершенно* ужасная цель.

> Можно просто ограничить функциональность на ровне интерфейса

Я уже много раз говорил это, но повторюсь: DRM это фундаментально плохая идея. Она не несет *ничего* хорошего.
С тех пор как я написал свой комментарий, я прочел несколько статей об «математической» обфускации программ,
и все еще считаю, что это бесполезная штука, которая может использоваться исключительно для DRM.

> i+=2 vs i++; i++;

1. Математически, это две одинаковые программы и они скомпилируются в один и тот же машинный код оптимизирующим компилятором.
2. Если они скомпилируются в разный код, то будут отличаться по таймигу.
3. Это не программа из реального мира.

> абсолютно некорректное утверждение.

История показывает обратное — люди разбирают существующие программы и неимоверное количество кряков в прошлом это весомый аргумент в мою сторону. Какие ваши аргументы?
Google Maps, рендереры Open Street Maps, FinalMesh.
Если обратить внимание на вот это предложение:
Технически это означает, что для начинающих программистов подсветка кода важна в большей степени, чем для опытных.
то можно сказать почему так происходит — для опытных программистов, пишущих операционные системы подсветка синтаксиса менее полезна. Но это не значит, что она вредна, или бесполезна для остальных.
Если честно, я не вижу фундаментальной разницы между ними. Да, они отличаются, но принцип — тот же.
При желании можно писать макросы как в CL:
gist.github.com/m1el/084477b3db4c5f6bd202
Perl 5 вышел в свет 20 лет назад :)
> Дальнейшее развитие DRM
Автор не слышал новости про White-box crypto

> Проблемы Digital Rights Management
> Наверное, главная технологическая проблема — открытость платформы.
Когда уже до управляющего звена дойдет, что DRM это фундаментально сломанная идея.
И единственная проблема DRM — это факт его существования. DRM неполноценен на уровне замысла.
Проблема в мозгах тех кретинов, которые считают, что DRM может решить какую-либо проблему касающуюся мультимедиа.

Максимум того что могут все существующие имплементации DRM для мультимедиа это вызывать проблемы для конечного пользователя.
Все существующие имплементации DRM были сломаны.

DRM не работает. DRM тратит ресурсы производства. DRM плох для конечного пользователя. DRM плох для архивации. DRM плох для ремиксов. DRM плох для цитирования. DRM плох для семьи. DRM убивает котят.

> Альтернативны Digital Rights Management в книгоиздании
Не использовать DRM.
Придет время и веб-индустрия поймет, что единственный адекватный подход к защите от XSS это:

  • Использовать DOM-based шаблоны вместо текстовых
  • Исключить использование inline-javascript в HTML, включая on* аттрибуты
  • Использовать Content-Security-Policy и X-Frame-Options: DENY
  • Фильтровать ссылки и адреса ресурсов, генерируемые динамически
Можно использовать и DOMDocument для генерации HTML, и это подходит под мой критерий. Но апи у него очень громоздкое.
В качестве примера того что я имею в виду я выберу React.js.
Я считаю, что генерация HTML при помощи DOM-подобных приемов это очень правильный подход, и автор пытается это сделать.

Но получается криво.
Хорошо. Я понял почему мой комментарий можно было принять как оскорбление.
Он не подразумервался как оскорбление.
1
23 ...

Информация

В рейтинге
Не участвует
Дата рождения
Зарегистрирован
Активность