Интересно! Но я точно не стал бы делать это на bash :) Синтаксис совсем непривычный, да linux пользуюсь не часто. А тот же js позволяет автоматизировать процессы нодой на линуксе и нодой или WSH под виндой.
Ну, относительно новый, почти год. Но я не стараюсь писать код с использованием последних нововведений стандартов, поскольку в клиентской части внедрение сдерживается браузерами и менее подконтрольно, чем версия ноды на сервере.
О каких классах речь? TypeScript? Или нативные есть?
Разумеется, что пример упрощён и этот подход там не оправдан. В рабочих проектах код несколько сложнее.
Кроме того, разбиение на блоки всё-таки помогает лучше воспринимать код, явно видеть законченные фрагменты алгоритма и понимать, в каких случаях ожидается обработка данных от второй стороны, в каких — нет. Кроме того, я отступаю от строгости КА и конечное состояние зависит не только от исходного и входящих данных, но и от других параметров. К примеру, при передаче удалённому клиенту больших порций данных с докачкой, я храню счётчик переданного (байтов, фрагментов...) в объекте ClientConnection и в состоянии, например, «передатьБлокБольшихДанных» зацикливаюсь, пока счётчик не укажет на последний фрагмент «больших данных».
Также в некоторых случаях приходится вычитывать буфер данных с удалённого датчика, работая в двух состояниях «ожидаемНовыйФрагментБуфера» и «обрабатываемНовыйФрагментБуфера». И только получив в первом состоянии код об опустошении буфера переключаться дальше.
Как минимум, потому что, к своему стыду, мне названные вами абстракции не были знакомы. Бегло посмотрев на генераторы, могу предположить, что его выполнение линейно, а мне в ряде случаев нужно оставаться в состоянии и обрабатывать некоторое количество событий сокета, а не переключаться сразу дальше. С асинхронными функциями сходу не понял, но, замечу, что использование машины состояний в моем коде не имеет явного отношения к асинхронности, промисам и проч.
На красивое «детское» решение мозги не сгодились, поэтому решал систему.
Пусть t — искомое время, тогда:
(21-t)vБ = S
(16-t)vA = S
(12-t)vA = S-(12-t)vБ
Неизвестных больше чем уравнений, но, выразив скорости через S и подставив в третье уравнение, получаем:
(12-t)S/(16-t) = S-(12-t)S/(21-t)
Разделив на S, избавимся от S и приведём
(12-t)/(16-t)=1 + (12-t)(21-t) к квадратному уравнению
t^2 -24t + 108 = 0
Два корня: 6 и 18.
Один из которых не подходит по смыслу.
Аналогично, спасибо за задачку. Давно так много не писал на бумаге :)
Хотя, квадратное уравнение всё-таки скормил вольфраму :)
Пардон, что лезу в ваш холивар.
Поддержу — классовое или прототипное, оно всё равно — ООП.
Но вот эта вся историческая мутагория в JS с контекстом и костылями типа bind — это вообще не про то. К чему это упоминать?
Нет, как раз в начальной школе мы этого и не требуем. И вообще — не требуем, что подразумевается в статье. Мы хотим соблюсти иногда противоречивые требования: сделать раскладку элементов как в печатном издании и сделать UX понятным и удобным.
Насчёт «пересечение максимально» — согласен, как вариант. Расстояние до позиции — уже спорно, неоднозначности могут быть.
Иногда неоднозначность только визуально определяется пользователем. Поэтому мы обязательно делаем подсветку. Но… в общем, в тексте статьи я описал вариации.
Да, альтренативные зоны — возможно. С их визуализацией при контакте?
Кстати! Я упустил еще один важный момент. Если мы пускаем интерактивн на доске — то это чертова куча дюймов, которые надо тащить объект. Поэтому изначально идея об использовании пересечений по областям пришла оттуда — чтобы меньше тянуться и метаться у интерактивной доски.
Большое спасибо за ценный опыт и готовность им делиться!
Подумаю насчет «intersect». Вариант с перетаскиванием «репрезентации» — тоже очень интересен. Согласен с примерами.
С рисованием линий — 50/50. Тут конечно линии временные, но, все-таки будет перекликаться с типом заданий на установление соответствий, где линии как раз и рисуются (но не временные, конечно). Хотя, смотря как обыграть анимацию по завершению действия.
Но есть еще момент — подложки в таких задания часто сами содержат линии — линии выносок подписей от рисунков, линии на схемах… Но, всё же, дверюсь вашему опыту — попробуем.
Отказаться от перетаскивания вообще — не можем. Есть задача разнообразить интерактивы именно с точки зрения UX. А не было бы — свели бы всё к спискам, чекбоксам и полям ввода с клавиатуры. Можем конечно в некоторых случаях. Но обычно сложные случаи мы трансформируем в серию заданий на одной подложке.
Кроме того, наша целевая аудитория — школа. А в начальной всё усугубляется :)
Не уловил смысл «Instructional value». Имеется ввиду суть задания?
1. В ряде случаев есть требование избегать прозрачности по максимуму. Кроме того, объекты-target небольшие даже в сравнении с пальцем
2. В некоторых случаях они так близко натыканы, что — нет. Например, мы ориентируемся на рисунок-схему из печатного издания, должны его повторить. Мы либо выбрасываем какие-то объекты-target, либо используем подход, который я описал.
Скажу больше — если неправильно расположить объекты-draggable, то визуально может получится каша. Объекты-draggable — блоки с текстом. После их drop'а оформление блока скрывается и остаётся только текст, который центрируется по центру объекта-target. Поэтому, если правильно расположить — будет копия того, что в печатном издании. А если неверно — то тексты могут пересекаться, заползать на рисунок и т.п.
В общем, это тот случай, когда мы вынуждены «плясать» от имеющегося оформления.
Если делаем подобное с нуля — конечно закладываем большие области, с оформлением или как вы указали.
Тут есть один момент. Хочется подсвечивать объекты-target и в случае коллизии. Например, цвета — оставим для подсветки ответов, а «потенциальный объект-target» в процессе drag-а будем оформлять, например, рисуя обводку. Жирную слошную у одного, если нет «коллизии», жирную пунктирную — у всех, с которыми «коллизия».
Собственно, разные стили — да, хорошо. Но поскольку я так и не встретил нигде решения, которое при drag-and-drop использует контакт областей, подумалось — не фигню ли городим?
Впервые сегодня писал расширение для Firefox, которое должно обрабатывать ссылки на расшаренные папки сервера и открывать их в проводнике под Windows. Столкнулся с тем, что с кирилицей в путях проблемы (хотя удивлен, что UTF-8 как раз и не понимается).
И вот — нагуглил. Так что спустя более, чем 4 года — пригодилось! Спасибо!!!
Хм. Возможно дело в моем непонимании порядка работы интерпретатора.
Если добавить код конфига в виде js-скрипта после кода подгрузки библиотеки — не получится. Если после — будет ОК.
Но я не понимаю, почему вообще такое возможно?
Я подключаю библиотеку как (function(window){/* ... */})(window);
Разве она не должна начать своё выполнение сразу по готовности скриптов?
С одной стороны уже есть глобальный объект Morfana, иначе не работал бы код конфигурации, с другой стороны — автостарта не происходит…
Как это может быть?
Здесь не может «race condition»? Т.е., если я пропишу код конфигурации строго после пдогрузки библиотеки, я могу быть уверен, что всегда будет работать?
Согласен, поэтому и используем подобные решения.
По органике — вот примеры: tex.stackexchange.com/questions/52722/can-you-make-chemical-structure-diagrams-in-latex
А насчет предлагаемого вами — оно хорошо в нашем случае: меньше «ассемблера», выше уровень абстракции, но конкретно отрисовка условных обозначений морфем или структурных формул решаются другими библиотеками?
У нас в их отсутствии загвоздка, а не в качественном комплексном шаблонизаторе во фронтенде, вот в чем дело.
Ну, подглядел у MathJax и упростил. Они, правда не затирают, а ставят отметку о факте обработки блока конфига. А сам код пихают в очередь обработки, а я сразу в eval.
А в чём криминал?
У меня была задача — минимум кода для дефолтного варианта использования библиотеки: подгрузилось — само запустилось — готово.
Для пользователя с минимумом требований.
А вот если нужно конфигурировать, то сперва нужно запретить автозапуск.
Был еще вариант — дописывать в script в путь к js-файлу параметры. Также делает MathJax. Но это, imho, хуже. И всё равно парсить и обрабатывать.
А! Вот такой «чистый CSS» — более приемлемый вариант. Разумеется, можно было сделать динамическую разметку span-ами, а не позиционировать svg-шки, как я сделал, но… смотрите:
Оставлять разметку span-ами на человека я не хотел — это усложняет ему задачу и, кроме того, пересекающиеся морфемы так не сделать (хотя, каюсь, я тогда о них не знал).
Допустим, я выбрал предлагаемый вами вариант и не думаю о пересечении морфем. Следовательно, основная задача библиотеки — правильно расставить span-ы. И вот тут я, конечно, нарушаю KISS, но предполагаю, что <span>слово</span> — это идеальный вариант. А может быть такой: <span>сл<b>о</b>во</span>. И, поверьте, такое встречается часто. Отмечают орфограммы в словах и тут же делаю морфемный разбор.
Я иду дальше, предполагаю, что разметка в слове может быть сложной и, главное, может статься так, что буквы одной морфемы лягут в разные элементы. И тогда я не смогу обернуть их в один span. Ну, например, в <span>пищевар<b>ени</b>е</span> надо выделить окончание «ие». Надуманно? Возможно. Но я пошел по такому пути. И позиционировал svg без span-ов. Тем более, если пересекающиеся мофемы — не редкость (я не знаю материалов школьной программы с углубленным изучением русского языка), то мой подход оправдан. А динамический разбор слова по номерам букв делается просто, строчными функциями — если слово написано сплошняком, без HTML. А если нет — тогда либо громоздить свой код, либо использовать Range (для этого там rangy собственно и исользуется).
Следует отметить, что я все-таки оборачиваю в span-ы некоторые буквы. А именно — первую и последнюю букву морфемы «окончание». Из-за её специфического вида нужны отступы. Но обратите внимание — только первую и последнюю (или одну — для однобуквенных окончаний). Раздельно. Работая на уровне единичных символов. Т.е. я всегда смогу обернуть букву в span.
Всё таки мне непривычно, но не буду торопиться с выводами — надо пробовать.
О каких классах речь? TypeScript? Или нативные есть?
Кроме того, разбиение на блоки всё-таки помогает лучше воспринимать код, явно видеть законченные фрагменты алгоритма и понимать, в каких случаях ожидается обработка данных от второй стороны, в каких — нет. Кроме того, я отступаю от строгости КА и конечное состояние зависит не только от исходного и входящих данных, но и от других параметров. К примеру, при передаче удалённому клиенту больших порций данных с докачкой, я храню счётчик переданного (байтов, фрагментов...) в объекте ClientConnection и в состоянии, например, «передатьБлокБольшихДанных» зацикливаюсь, пока счётчик не укажет на последний фрагмент «больших данных».
Также в некоторых случаях приходится вычитывать буфер данных с удалённого датчика, работая в двух состояниях «ожидаемНовыйФрагментБуфера» и «обрабатываемНовыйФрагментБуфера». И только получив в первом состоянии код об опустошении буфера переключаться дальше.
Пусть t — искомое время, тогда:
(21-t)vБ = S
(16-t)vA = S
(12-t)vA = S-(12-t)vБ
Неизвестных больше чем уравнений, но, выразив скорости через S и подставив в третье уравнение, получаем:
(12-t)S/(16-t) = S-(12-t)S/(21-t)
Разделив на S, избавимся от S и приведём
(12-t)/(16-t)=1 + (12-t)(21-t) к квадратному уравнению
t^2 -24t + 108 = 0
Два корня: 6 и 18.
Один из которых не подходит по смыслу.
Аналогично, спасибо за задачку. Давно так много не писал на бумаге :)
Хотя, квадратное уравнение всё-таки скормил вольфраму :)
Поддержу — классовое или прототипное, оно всё равно — ООП.
Но вот эта вся историческая мутагория в JS с контекстом и костылями типа bind — это вообще не про то. К чему это упоминать?
Насчёт «пересечение максимально» — согласен, как вариант. Расстояние до позиции — уже спорно, неоднозначности могут быть.
Иногда неоднозначность только визуально определяется пользователем. Поэтому мы обязательно делаем подсветку. Но… в общем, в тексте статьи я описал вариации.
Кстати! Я упустил еще один важный момент. Если мы пускаем интерактивн на доске — то это чертова куча дюймов, которые надо тащить объект. Поэтому изначально идея об использовании пересечений по областям пришла оттуда — чтобы меньше тянуться и метаться у интерактивной доски.
Подумаю насчет «intersect». Вариант с перетаскиванием «репрезентации» — тоже очень интересен. Согласен с примерами.
С рисованием линий — 50/50. Тут конечно линии временные, но, все-таки будет перекликаться с типом заданий на установление соответствий, где линии как раз и рисуются (но не временные, конечно). Хотя, смотря как обыграть анимацию по завершению действия.
Но есть еще момент — подложки в таких задания часто сами содержат линии — линии выносок подписей от рисунков, линии на схемах… Но, всё же, дверюсь вашему опыту — попробуем.
Отказаться от перетаскивания вообще — не можем. Есть задача разнообразить интерактивы именно с точки зрения UX. А не было бы — свели бы всё к спискам, чекбоксам и полям ввода с клавиатуры. Можем конечно в некоторых случаях. Но обычно сложные случаи мы трансформируем в серию заданий на одной подложке.
Кроме того, наша целевая аудитория — школа. А в начальной всё усугубляется :)
Не уловил смысл «Instructional value». Имеется ввиду суть задания?
Насчет QA — не подумал. Хотел на Тостер, но мне важен не конкретный ответ, а мнение многих — поэтому добавил опрос.
2. В некоторых случаях они так близко натыканы, что — нет. Например, мы ориентируемся на рисунок-схему из печатного издания, должны его повторить. Мы либо выбрасываем какие-то объекты-target, либо используем подход, который я описал.
Скажу больше — если неправильно расположить объекты-draggable, то визуально может получится каша. Объекты-draggable — блоки с текстом. После их drop'а оформление блока скрывается и остаётся только текст, который центрируется по центру объекта-target. Поэтому, если правильно расположить — будет копия того, что в печатном издании. А если неверно — то тексты могут пересекаться, заползать на рисунок и т.п.
В общем, это тот случай, когда мы вынуждены «плясать» от имеющегося оформления.
Если делаем подобное с нуля — конечно закладываем большие области, с оформлением или как вы указали.
Собственно, разные стили — да, хорошо. Но поскольку я так и не встретил нигде решения, которое при drag-and-drop использует контакт областей, подумалось — не фигню ли городим?
И вот — нагуглил. Так что спустя более, чем 4 года — пригодилось! Спасибо!!!
Если добавить код конфига в виде js-скрипта после кода подгрузки библиотеки — не получится. Если после — будет ОК.
Но я не понимаю, почему вообще такое возможно?
Я подключаю библиотеку как
(function(window){/* ... */})(window);Разве она не должна начать своё выполнение сразу по готовности скриптов?
С одной стороны уже есть глобальный объект Morfana, иначе не работал бы код конфигурации, с другой стороны — автостарта не происходит…
Как это может быть?
Здесь не может «race condition»? Т.е., если я пропишу код конфигурации строго после пдогрузки библиотеки, я могу быть уверен, что всегда будет работать?
По органике — вот примеры: tex.stackexchange.com/questions/52722/can-you-make-chemical-structure-diagrams-in-latex
А насчет предлагаемого вами — оно хорошо в нашем случае: меньше «ассемблера», выше уровень абстракции, но конкретно отрисовка условных обозначений морфем или структурных формул решаются другими библиотеками?
У нас в их отсутствии загвоздка, а не в качественном комплексном шаблонизаторе во фронтенде, вот в чем дело.
А в чём криминал?
У меня была задача — минимум кода для дефолтного варианта использования библиотеки: подгрузилось — само запустилось — готово.
Для пользователя с минимумом требований.
А вот если нужно конфигурировать, то сперва нужно запретить автозапуск.
Был еще вариант — дописывать в script в путь к js-файлу параметры. Также делает MathJax. Но это, imho, хуже. И всё равно парсить и обрабатывать.
Про pointer-events не слышал. Посмотрю, спасибо. Если это аналог mouseEnabled/mouseChildren из Flash — замечательно.
Спасибо!
Оставлять разметку span-ами на человека я не хотел — это усложняет ему задачу и, кроме того, пересекающиеся морфемы так не сделать (хотя, каюсь, я тогда о них не знал).
Допустим, я выбрал предлагаемый вами вариант и не думаю о пересечении морфем. Следовательно, основная задача библиотеки — правильно расставить span-ы. И вот тут я, конечно, нарушаю KISS, но предполагаю, что <span>слово</span> — это идеальный вариант. А может быть такой: <span>сл<b>о</b>во</span>. И, поверьте, такое встречается часто. Отмечают орфограммы в словах и тут же делаю морфемный разбор.
Я иду дальше, предполагаю, что разметка в слове может быть сложной и, главное, может статься так, что буквы одной морфемы лягут в разные элементы. И тогда я не смогу обернуть их в один span. Ну, например, в <span>пищевар<b>ени</b>е</span> надо выделить окончание «ие». Надуманно? Возможно. Но я пошел по такому пути. И позиционировал svg без span-ов. Тем более, если пересекающиеся мофемы — не редкость (я не знаю материалов школьной программы с углубленным изучением русского языка), то мой подход оправдан. А динамический разбор слова по номерам букв делается просто, строчными функциями — если слово написано сплошняком, без HTML. А если нет — тогда либо громоздить свой код, либо использовать Range (для этого там rangy собственно и исользуется).
Следует отметить, что я все-таки оборачиваю в span-ы некоторые буквы. А именно — первую и последнюю букву морфемы «окончание». Из-за её специфического вида нужны отступы. Но обратите внимание — только первую и последнюю (или одну — для однобуквенных окончаний). Раздельно. Работая на уровне единичных символов. Т.е. я всегда смогу обернуть букву в span.