Александр Попов

https://habr.com/post/60362/

Провёл эксперименты и по всей видимости понял в чём дело. В том, что всё работает именно так, как я пишу ниже, до конца быть уверенным не могу. Но по трезвому размышлению, это вполне правдоподобно.

Папка Dropbox на компьютере — это не обычная папка Windows. Файлы и каталоги в ней каким-то образом индексируются. Т.е. файл помимо имени и других атрибутов файловой системы, имеет какой-то свой "дропбокс-идентификатор". Дело в том, что например при переименовании файла, для Дропбокса он остаётся тем же файлом. Перменование для него — это переименование, а не удаление одного файла и появление совершенно нового с другим именем. В последнем бы случае Дропбоксу подабоилось бы по-новому его закачикавать к себе целиком, что очевидно не происходит.

Поэтому когда я перекинул средствами Windows те же каталоги и файлы в папку Dropbox на другом компьютере, с точки зрения Дропбокса это были какие-то другие файлы, т.к. их дропбокс-идентификаторы и атрибуты при таком копировании "мешком" с ними вместе не копируются. Поэтому Дропбокс расценил их как новое содержимое, но к несчастью имеющие те же имена файлов, что и уже хранящиеся в облаке. Отсюда он их продублировал, отметив как "конфликт синхронизации".

Вывод-рецепт такой: Нельзя копировать файлы, которые должны быть синхронны, между разными устройствами в обход Дропбокса! Придётся на новом устройстве установить Дропбокс, назначить ему папку и ждать, пока он в эту папку насосёт файлы из облака. Ни в коем случае не наливать файлы самому.

Планируется разработка пульта управления

это "рычаги" для управления "двигателем".

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

это сам "двигатель", который реализуется микро-сервисами.

Ваш вопрос про "рычаги".

Если задачи "двигателя" требуют высокой скорости исполнения - это микросервисы, которые реализуются (как правило) на C и запускаются как демоны в ОС.
Иначе - не важно на чём создавать: разницы и прироста производительности не увидите.

PS: Многое зависит от корректной логики реализуемого алгоритма, правильного кеширования и индексирования обрабатываемых данных!

1. Как в рантайме правильнее разграничить вызов нативных (реализованных на Java) функций и вызов функций на JavaScript (это весьма разные сущности)?

Ну сделай разные классы для разных функций. JS динамически типизированный, так что в основном ты все равно будешь работать с каким-нибудь базовым абстрактным JsValue, от него и унаследуй классы функций. У класса JsValue сделай метод

JsValue call(scope: JsScope, context: JsValue, args: ArrayList<JsValue>)

который кидает TypeError: бла-бла-бла is not a function, а в классах функций (JsNativeFunction и JsFunction) переопредели его чтобы возвращал что-то.

2. Как оптимальнее хранить scopes? Через Hashtable/HashMap в виде вектора (имитация стека) - нормальное решение?

Я не эксперт, но я делал скоуп в виде хешмапа со ссылкой на родительский скоуп (и так по ссылкам можно было соответственно дойти до глобального скоупа), вроде нормальный вариант.

3. Как правильно организовать поиск функций в цепочке прототипов объекта? Например, мы ищем функцию; она находится в прототипе, ссылку на который мы храним. Но при вызове такая функция должна работать с полями данных исходного объекта, а не прототипа, или прототипа прототипа и т.д. В JavaScript всё будет в такой ситуации работать корректно, а как такое грамотно эмулировать?

Не вижу проблемы. x.foo(42) разворачивается во что-то типа этого:

JsObject xVar = scope.getVar("x");
xVar
    .attr("foo")    // ищет атрибут в объекте или в прототипе
    .call(scope, xVar, Arrays.asList(JsInt(42)));

Второй параметр метода call - это и есть контекст, то есть объект у которого вызывается метод.

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

Тут вряд ли что-то толковое подскажу, кроме как посмотреть в сторону ANTLR и аналогов.

P. S.
Немного литературы по теме

Всё дело в том, что this в A.foo ссылается не на A, а на инстанс B. А поиск метода идёт по цепочке прототипов, начиная сверху, поэтому до A.bar никогда не доходит.
Рассуждать, логично это или нет, бессмысленно - это просто так и нужно принять такое поведение, понять его и использовать.

И нет, в Java и C++ поведение не такое. Вообще, в javascript наследование прототипное и есть закидоны особенности с контекстом вызова, поэтому привычное из других языков понимание ООП в нём не всегда работает.

Зависит от того, уникальна пара (user_id, tag_id) или нет.
Для уникальных всё просто

SELECT `u`.*
  FROM `users` AS `u`
  JOIN `user_tags` AS `ut` ON `ut`.`user_id` = `u`.`id`
    AND `ut`.`tag_id` IN (1, 2, ..., N)
  GROUP BY `u`.`id`
  HAVING COUNT(*) = N

Для неуникальных добавляется DISTINCT

SELECT `u`.*
  FROM `users` AS `u`
  JOIN `user_tags` AS `ut` ON `ut`.`user_id` = `u`.`id`
    AND `ut`.`tag_id` IN (1, 2, ..., N)
  GROUP BY `u`.`id`
  HAVING COUNT(DISTINCT `ut`.`tag_id`) = N

Если мы говорим именно о адаптивной версии (не тупо резина) - то однозначно рисуются отдельные версии дизайна под N поддерживаемых разрешений, дальше это все верстается.
Число N субъективно, от 2 (десктоп, мобайл) через бутстраповские 4 и до до скольки угодно (под все основные разрешения клиентов)