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

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

Решаем вопрос сортировки в JavaScript раз и навсегда

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

Решаем вопрос сортировки в JavaScript раз и навсегда

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

Решаем вопрос сортировки в JavaScript раз и навсегда

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

Решаем вопрос сортировки в JavaScript раз и навсегда

[ответ не туда]

Решаем вопрос сортировки в JavaScript раз и навсегда

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


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


  • сравнение чисел через compare_numb можно делать через compare_string и не обрабатывает NaN.
  • использование строк как ключей объектов не позволяет использовать TypeScript и более сложные выражения
  • я намеренно стремлюсь использовать сортировку именно по ключу, потому что это более очевидно для использования
  • бинарный поиск так же можно использовать, имея функцию ключа

Решаем вопрос сортировки в JavaScript раз и навсегда

Большое спасибо, исправлено!

Решаем вопрос сортировки в JavaScript раз и навсегда

Совершенно верно, и библиотека thenby использует именно этот подход.

Обфускация программ

Да, я уже говорил, что я читал научные статьи про математическую обфускацию.
Основная проблема, которую я вижу — есть классы функций, которые нельзя безопасно обфусцировать,
и есть *некоторые* функции, для которых придумали обфускацию. Этих функций очень мало, они «скучные» или их роль может выполнить другим путем.

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

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

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

Зачем?

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

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

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

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

Обфускация программ

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

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

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

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

История показывает обратное — люди разбирают существующие программы и неимоверное количество кряков в прошлом это весомый аргумент в мою сторону. Какие ваши аргументы?

WebGL для всех

Google Maps, рендереры Open Street Maps, FinalMesh.

Пользуйтесь подсветкой кода

Если обратить внимание на вот это предложение:
Технически это означает, что для начинающих программистов подсветка кода важна в большей степени, чем для опытных.
то можно сказать почему так происходит — для опытных программистов, пишущих операционные системы подсветка синтаксиса менее полезна. Но это не значит, что она вредна, или бесполезна для остальных.

Метапрограммирование: какое оно есть и каким должно быть

Если честно, я не вижу фундаментальной разницы между ними. Да, они отличаются, но принцип — тот же.
При желании можно писать макросы как в CL:
gist.github.com/m1el/084477b3db4c5f6bd202

GOTO or not GOTO вот в чём вопрос

Perl 5 вышел в свет 20 лет назад :)

Мастер-класс Дмитрия Склярова. DRM: вчера, сегодня и завтра

> Дальнейшее развитие 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
  • Фильтровать ссылки и адреса ресурсов, генерируемые динамически

Генерация html на PHP

Можно использовать и DOMDocument для генерации HTML, и это подходит под мой критерий. Но апи у него очень громоздкое.
В качестве примера того что я имею в виду я выберу React.js.

Генерация html на PHP

Я считаю, что генерация HTML при помощи DOM-подобных приемов это очень правильный подход, и автор пытается это сделать.

Но получается криво.

Осциллоскоп на WebGL

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

Информация

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