Есть вопрос о работе блокировок. Они для https-сайтов вообще отслеживают что в DNS мог адрес поменяться?

Будет ли работать такой квест:

- создаем сайт
- добиваемся блокировки домена
- меняем IP на яндекс, jquery, youtube и т.п.

Типа, если фильтр настолько уязвим, что подобные проблемы могут случаться каждый день, то встает вопрос о чего нужности.

У меня очередной приступ копирастии и новые вопросы :)

Хочу формализовать в правилах форума лицензию на контент. Чтобы он был CC-BY. Соответственно, если кто-то копирует материал форума, он должен поставить ссылку на оригинальное сообщение (типа того)

А где при этом обычно указывают как оформлять ссылки на источник? Это не входит в текст самой лицензии и по-моему дописывается отдельно. Есть какие-то общепринятые способы и примеры?

Интересуют тулзы для сборки больших приложений (именно приложений, а не библиотек как rollup.js). Хочу променять свой лисапед на что-то более стандартное.

В принципе, webpack похож на то что надо, но меня напрягает в нем некоторая монструозность и детские болезни:

- В трекере много тикетов где указано время сборки несколько минут (это очень долго)
- До сих пор нет (или не увидел) кеширования на диск собираемых модулей
- Не поддерживается автоматического заворачивания webworker в ссылку (аналог webworkify из browserify), искал очень внимательно.
- Ну и вообще в трекере многовато тикетов, слишком стремных для стабильного проекта.

Есть ли у кого-нибудь истории успеха с вебпаком? Или истории успеха по сваливанию с вебпака (куда?).

Нужно иногда профессиональную правку текстов делать и про законы об интернетах уточнять.

Есть ли сайты, где можно отыскать подходящих специалистов по сходной цене?

Есть 2 вида данных, для которых хочется вести историю изменений:

- Сообщения юзеров. Их может редактировать только автор и админы.
- wiki-странички. Их может редактировать то угодно, но есть опциональная премодерация.

С юзерами вроде все понятно, с вики не очень. С одной стороны потребности wiki напоминают git, но с другой - никто же не будет заниматься параллельными бранчами и разруливанием конфликтов (юзерам квалификации не хватит). Да и в интерфейсе в итоге реально показывать только линейную историю.

Нужен пинок в правильном направлении, где подобные вещи сделаны правильно и удобно. Сама википедия в качестве примера не очень устраивает, т.к. там нет премодерации, из-за которой могут накопиться параллельные правки.

https://ru.wikipedia.org/wiki/Лицензия_MIT

В первой строчке надо указывать год и владельца прав. Что там можно написать, если я не хочу указывать себя? Чтобы лицензия оставалась корректной.

В гугле ответа не нашел.

Хотелось бы чего-то вроде lodash - туда всегда можно заглядывать, чтобы посмотреть какие бывают типовые операции, и как их правильно реализовывать.

В ноде с потоками какая-то каша - stream1, stream2, stream3. И все это разбрызгано на 100500 библиотек. Голова пухнет, трудно каждый раз найти что надо.

Кто-нибудь может посоветовать современный tutorial или общую библиотеку?

...через nuxt или как-то еще. Как там вообще с производительностью? Читаю вот этот мануал, все вроде красиво и правильно. Но в трекере висят тикеты с предложениями по оптимизации, где подозрительно большие цифры указывают (300+ ms). Правда не знаю насколько сложные там страницы.

А вообще VUE с виду приятен и понятен. В отличие от react и angular :)

Изучаю vue.js и пытаюсь понять, как на него правильно перетащить текущий код. То что компоненты надо делать изолированными - это понятно. То что стейт фигарить через глобальный стор - тоже.

Но помимо этого хочется еще несколько вещей. Возможно, хочется неправильно и зря, тогда поправьте как надо:

1. Как вообще принято переводы делать? Сейчас у меня весь яваскрипт фигарится в общий бандл, и делаются отдельный бандлы для каждого языка. Типа, клиент один раз грузит нужный язык и на ходу переключать не надо.

2. Вроде как логично переводы внутри компонентов держать, но внутри .vue ничего для подобного не предусмотрено (расширить-то можно, но не хочется лисапедить).

3. Хотя переводы в основном привязаны к компонентам, бывают еще и глобальные. А как принято к ним лезть, и как показывать, что в одном месте нам нужен локальный перевод, а в другом глобальный.

4. Иногда хочется внешние константы в шаблон заэмбедить. Например, в конфиге приложения я задаю размеры превьюшек. А потом их надо явно указать в стилях. Или, например, в темплейте мне нужно испортнуть структуру со статусами, типа { visible: 1, closed: 2, deleted: 3 }. Лучше бы такое сразу заэмбедить и не дергать хелперы при рендеринге. У меня в кастомном лисапеде под это есть макросы с отслеживанием зависимостей, но не уверен что такое в vue прокатит.

5. При использовании всяких vueify и vue-loader, можно ли сделать так, чтобы stylus понимал npm-пути в @import? То же самое касается jade и т.п.

6. Вопрос больше про vueify и vue-loader. У меня есть несколько приложений, хочется «смержить» их файловую систему. Чтобы когда указывают относительные пути, компонент на этапе бандлинга искался по всем приложениям, а не только по текущему. Это бывает удобно если хочется организовать виджеты в дерево, вместо одной плоской кучи-малы.

https://github.com/nodemailer/nodemailer/blob/master/CHANGELOG.md#v400-2017-0...

Андрис похоже решил свои финансовые ожидания и перестал заниматься террором с лицензиями :). На сайте проекта тоже нигде не обнаружил намеков на платные расширения.

Так что теперь он не злобный уничтожитель сорцов в куче репов, а снова уважаемый человек, объединивший все плагины в общий проект.

Надеюсь, у него теперь все хорошо. Поздравил его донатом во имя луны и MIT.

В новых браузерах есть фича createImageBitmap, которая, судя по документации, должна уметь качественно ресайзить картинки (в отличие от канвасовского drawImage). Но у меня почему-то никак не получается заставить эту фичу работать (уменьшать картинку). Что с опциями, что без них, работает одинаково - ни фига не ресайзит.

createImageBitmap(img, 0, 0, 3264, 2448, { resizeWidth: 500, resizeHeight: 500, resizeQuality: "high" })
  .then(b => {
    console.log(b); // => тут размер всё еще 3264*2448 :(
  })

https://github.com/nodeca/multimath

Продолжаю развлекаться с webassembly. Нужна помощь в перетаскивании жабаскриптового кода на сишечку. Сам сделать могу, но по сишечке не спец, да и не особо люблю.

Нужно для начала перетащить на си unsharp mask (включая gaussian blur). Сорцы на жабаскрипте, небольшие, понятные. Рыба чтобы все интегрировать в кучу, есть, что непонятно - помогу. Жабаскриптовые обертки тоже напишу какие надо.

Я пытаюсь оформить удобную библиотеку, которая в новых браузерах юзала бы wasm, а в старых откатывалась на жабасрипт. Конечная цель - сформировать удобное апи для клепкания подобных компактных универсальных модулей. Например, face detection виоладжонсом и т.п.

Если кто-то хочет поучаствовать, прославиться, улучшить мир и т.п. - пишите на vitaly@rcdesign.ru или сюда. По денежке что-нибудь придумаем.

http://nodeca.github.io/pica/demo/

Дошли руки причесать ресайзилку картинок. Годная тема для уменьшения размера аплоадов, если у вас не форум фотографов.

- апи поменялось: теперь все через промисы, и можно явно указать настройки пула вебворкеров.
- добавлена поддержка WebAssembly, пока из любопытства, чиста поржать
- добавлена поддержка createImageBitmap для неблокирующей распаковки картинок (ресайз через него какбэ тоже добавлен, но пока его никто не умеет)
- пофикшены регрессии скорости в последних хромах
- выпилена поддержка WebGL, т.к. его за год так и не довели до вменяемого состояния.

Потестите, что как. Если кто-то использует и есть замечания насчет API - пишите, пока не зарелизил.

Заметил тормоза только на мобильном фаерфоксе.

Еще заметно что вебворкеры не очень быстро стартуют, но если надо обработать пачку картинок подряд, то в 4 ядра фигарит весьма задорно даже на мобилке.

https://github.com/foo123/HAAR.js/tree/master/cascades

Интересует каскад с человечьими мордами, от интела. Если упаковать текстовый файл получается ~60-70 килобайт. Многовато. Раза в три уменьшить реально или фантастика?

Нужно уменьшить картинку, классическим фильтром Ланцеша с окном 3. Расчет таблички фильтра, вертикальный и горизонтальный конвольверы, все понятно.

Есть вопрос насчет реализации. Я знаю 2 варианта:

1. Делаем горизонтальный проход, отписываем повернутые координаты, чтобы вертикальный проход опять шел по строкам, и эффективнее выгребал банки памяти.

2. Проходим несколько строк по горизонтали, и как только набежит достаточно - делаем «шажок» вертикального конвольвера. То есть, они дрюкаются попеременно. Из плюсов - надо меньше промежуточной памяти, хотя доступ к ней более рандомный.

Вариант (1) вроде как классический. Вариант (2) видел в гугловской библиотеке Skia. Вопрос, а что лучше-то по скорости? И стоит ли (2) того, чтобы уродоваться с кодом?

Ну еще конечно толстые картинки нарезаем предварительно на тайлы, но меня интересует именно возможность улучшения скорость конвольверов. У меня создалось впечатление, что все уходит в умножение. По крайне мере, когда читал пиксели по байтам и по словам, разницы практически не было (к моему большому удивлению).

Я тут как-то упоминал, что от общения с майкрософтовскими программистами на гитхабе у меня осталось весьма приятное впечатление. Они пишут прекрасные issues, могут сами разобраться в моем коде, в котором перестал разбираться я сам и т.п. Создалось впечатление, что их как-то сильно фильтруют, перед тем как на гитхаб выпускать.

И тут я увидел ЭТО. Вротмненоги...

Я знаю про benchmark.js, но он слишком низкоуровневый.

Хотелось бы писать бенчмарки в стиле mocha, и чтобы сразу красивые странички генерились. Есть что-то готовое и актуальное для подобного? Желательно чтобы те бенчмарки в ноде тоже можно было пускать.

https://github.com/puzrin/convolve-wasm/tree/32bit

Поразбирался еще немного, какой можно получить профит от WebAssembly на числодробилках. Для примера была взята ресайзилка картинок, где гоняются конвольверы. Код из предыдущего топика был сильно почищен, и добавлен вариант с выборкой пикселей как 32-битных чисел, вместо 4 раз по 1 байту.

Получилось так:

1. В фаерфоксе скорость почти прежняя. 300мс на жабаскрипте, 250мс на wasm.
2. В хроме стало меньше тупить. 300мс на яваскрипте, 270мс на wasm.

Мало. Грустно. А самое странное, почему сокращение операций с памятью почти не дало профита? По ссылке ассемблерный код, который генерит FF из wasm (прогнал через webassembly explorer):

https://gist.github.com/puzrin/fb8ed64a9f3473b86334f798eabf2de0

Что еще можно подкрутить? Идеи кончились.

Сейчас Dron перегоняет числодробилку для ресайза картинок на webassembly. Временно посмотреть можно тут: https://github.com/fedor-elizarov/convolve-wasm

То, что яваскрипт делает за 300мс, WA делает за 250мс.

Результат, мягко говоря, не впечатляет. Оказывается яваскриптовый JIT очень нефигово оптимизирует код. Еще конечно есть возможность оптимизировать работу с памятью, НО если копировать логику 1:1, то результат слабенький.

Вторая пичалька в том, что у WA пока нет поддержки SSE. А из v8 гугель внезапно выпилил SIMD https://bugs.chromium.org/p/v8/issues/detail?id=4124. Вроде они его выпилили в пользу будущего WA, но в итоге нигде нет.

Продолжаю наблюдать :)

UPD. Поставил Хром 57. В нем WA отрабатывает за 500мс против 300мс на яваскрипте.

Нужно потестировать имплементацию starttls в NNTP-сервере на чем-то настоящем. По этой причине вариант «законнектится на 563 порт и не париться» не подходит.

Кто-то из клиентов вообще умеет starttls или это так и осталось влажными фантазиями в rfc4642?