Boustrophedon (/ˌbuːstrəˈfiːdən/[1]) is a style of writing in which alternate lines of writing are reversed, with letters also written in reverse, mirror-style. This is in contrast to modern European languages, where lines always begin on the same side, usually the left.
Да легко, это точно не представляет технической проблемы при отображении.
Но например для распознавания такого текста точно будут нужны особые правила.
менее затратно обучить 100500 индусов, у которых в каждой деревне свой язык,
Не все в жизни определяется «финансовыми затратами», есть вполне себе бесценные вещи вроде сохранения культурного наследия, ради которого и создаются все эти шрифты и локализации.
Поэтому задача локализации и перевода на редкие языки никогда не потеряет своей актуальности.
Ну скажу честно что озадачил только вариант с «по спиралям» (такое есть?), остальное врядли представляет какую‑либо техническую сложность.
Очевидно что будет использоваться точно такая же транслитерация во всех местах кроме непосредственного отображения пользователю, а смена направления записи легко управляется на стадии отображения, даже если речь не про веб а что-то настольное.
Определенную проблему представляют «спецэффекты», когда например пользователь вводит арабский текст в поле ввода и он автоматически меняет направление ввода.
Но если обойтись без них — направление ввода легко поменять на стадии обработки ввода.
подключить к аппаратно-программному комплексу raspberry pi
Есть очень большая разница между бытовой электроникой и промышленной. Проще говоря ваш raspberry pi в цеху при серьезной и постоянной нагрузке просто сгорит.
Как и большинство бытовых компьютеров — попробуйте например соорудить домашний сервер из ноутбука и воочию увидите как он выходит из строя в страшных муках. Не надо так делать в общем.
но со стороны бэкпортирование кажется излишне бесполезным занятием
А если скажу, что до сих пор выпускаются 3.5 дискеты (см. дату выпуска партии) — сильно удивитесь?
Недавняя история с поиском сисадмина для сети на базе Windows 3.1 в немецкую железнодорожную компанию на самом деле не является уникальной, очень много где используются еще более древние системы.
И под них до сих пор пишут и поддерживают софт.
И делают бекпорты, хотя разумеется речь не про портирование чего-то вроде Node.js на Windows 3.1.
Но ведь разрабатывать можно
С заметно большим трудом. И чем более устаревшее окружение — тем сложнее и дороже.
Таким вот бекпортом мы cильно удешевили и ускорили разработку, позволив обычным современным Node.js разработчикам с 3–5 лет опыта разрабатывать без оглядки на реалии системы которой на минуточку уже 15 лет.
Вообще‑то речь про тестовые стенды, а то что вы описываете уже не совсем оно, поскольку тут начинаются пересечения с продуктовой средой.
Я такое не одобряю, поскольку это ограничивает возможности по тестированию — размывается граница того где заканчивается продуктовый контур и начинается тестовый, перестает быть понятно что можно трогать в рамках тестирования а что нет.
Но отвечая на ваш вопрос: да, это тоже решаемо — эмуляцией такого провайдера своим тестовым.
Разумеется при такой работе придется докручивать еще наборы отдаваемых полей с данными, поскольку они разные у разных поставщиков.
Дело в том что этот проект maglev берется из chromium, из движка v8 и копируется в Node.js как зависимость.
Насколько я понял, сама разработка maglev на стороне Node.js не ведется вообще, его просто копируют из апстрима, поэтому например разница в этом месте между 20й и 22й Node.js очень большая — концов не найти.
Самая главная проблема что уже достаточно давно нет возможности сделать «admin/admin» даже для тестов — теперь все хотят сложные пароли. И разумеется никакой nginx не поможет из‑за CSRF проверок.
Для OAuth/SSO все тоже самое, просто отключение проверки пароля происходит на стороне OAuth сервера, после чего он спокойно авторизует клиентов. Проверено.
Да, я поздно понял что можно было просто переменной окружения пропускать эту проверку :) Но вот все остальное (где про замену файлов) делать не советую.
Node-gyp кстати в моей сборке очень даже работает.
Понимаю что вам очень хочется обвинить меня в некомпентности, но увы:
Это абсолютно рабочее решение, которое используется уже 10 лет на своих и чужих проектах, которые через нас проходят. И каких-либо проблем до сих пор не было.
Реализация подменяется не в каком-то одном BCryptPasswordEncoder а во всех, включая кастомные (если они присутствуют в проекте)
Так что все с этим проектом хорошо, рекомендую к использованию.
История с профилями заканчивается на моменте использования чужого решения. Врядли получится поиграться с профилями в чужом закрытом проекте, даже если там тоже используется Spring.
Профили это плохо, поскольку у вас начнут отличаться среды выполнения для теста и продакшна. Что означает например возможность получить невоспроизводимые ошибки - на проде есть, на тесте не воспроизводится.
Ну и будут проблемы с библиотеками, которым нужна актуальная версия, будет проблема с node‑gyp и линковкой нативных частей, которых очень много — от sass компилятора и до драйверов к СУБД.
Потому что устаревший рантайм потянет за собой необходимость сборки с помощью устаревших инструментов, т.е. в данном случае пришлось бы всю разработку целиком проводить на старой версии Node.js.
Также не стоит забывать что речь идет о Node.js, для которой фразы «пожалуйста обновитесь» и «используйте последнюю версию» являются официальным руководством к действию от ее разработчиков, а «обратная совместимость» — грубым ругательством.
Но концептуально вы правы — в большинстве случаев при работе со «средневековыми» версиями действительно приходится разворачивать еще и «средневековую» разработку.
Скорее постепенно убирает слои совместимости, от версии к версии уменьшая возможности по работе устаревшего ПО.
На сегодняшний день для софта уровня DOS/Win3.1/Win95 уже чуть ли не официально рекомендуют использовать Wine или Dosbox вместо того чтобы пытаться запускать в основной ОС.
Не поверите но как минимум попытка реализовать «круговой интерфейс» уже была:
Так что техническая часть все также не представляет проблемы. Но разумеется тут будет уже полный кастом всего.
Boustrophedon (/ˌbuːstrəˈfiːdən/[1]) is a style of writing in which alternate lines of writing are reversed, with letters also written in reverse, mirror-style. This is in contrast to modern European languages, where lines always begin on the same side, usually the left.
Да легко, это точно не представляет технической проблемы при отображении.
Но например для распознавания такого текста точно будут нужны особые правила.
Не все в жизни определяется «финансовыми затратами», есть вполне себе бесценные вещи вроде сохранения культурного наследия, ради которого и создаются все эти шрифты и локализации.
Поэтому задача локализации и перевода на редкие языки никогда не потеряет своей актуальности.
Ну скажу честно что озадачил только вариант с «по спиралям» (такое есть?), остальное врядли представляет какую‑либо техническую сложность.
Очевидно что будет использоваться точно такая же транслитерация во всех местах кроме непосредственного отображения пользователю, а смена направления записи легко управляется на стадии отображения, даже если речь не про веб а что-то настольное.
Определенную проблему представляют «спецэффекты», когда например пользователь вводит арабский текст в поле ввода и он автоматически меняет направление ввода.
Но если обойтись без них — направление ввода легко поменять на стадии обработки ввода.
Напомню что только в РФ живет 130 разных народов, у каждого из которых есть свой язык.
А еще есть Индия и целый африканский континент, где на каждую деревню по своему языку.
Замените клингонский на например 'удмуртский' и все поймете — принципы локализации одинаковы.
Выложил вот тут: https://filetransfer.io/data-package/zOkMP8uP#link обе сборки.
>Не собирать же самому по этим гайдам...
Это не настолько сложно как кажется.
Есть очень большая разница между бытовой электроникой и промышленной. Проще говоря ваш raspberry pi
в цехупри серьезной и постоянной нагрузке просто сгорит.Как и большинство бытовых компьютеров — попробуйте например соорудить домашний сервер из ноутбука и воочию увидите как он выходит из строя
в страшных муках. Не надо так делать в общем.А если скажу, что до сих пор выпускаются 3.5 дискеты (см. дату выпуска партии) — сильно удивитесь?
Недавняя история с поиском сисадмина для сети на базе Windows 3.1 в немецкую железнодорожную компанию на самом деле не является уникальной, очень много где используются еще более древние системы.
И под них до сих пор пишут и поддерживают софт.
И делают бекпорты, хотя разумеется речь не про портирование чего-то вроде Node.js на Windows 3.1.
С заметно большим трудом. И чем более устаревшее окружение — тем сложнее и дороже.
Таким вот бекпортом мы cильно удешевили и ускорили разработку, позволив обычным современным Node.js разработчикам с 3–5 лет опыта разрабатывать без оглядки на реалии системы которой на минуточку уже 15 лет.
Вообще‑то речь про тестовые стенды, а то что вы описываете уже не совсем оно, поскольку тут начинаются пересечения с продуктовой средой.
Я такое не одобряю, поскольку это ограничивает возможности по тестированию — размывается граница того где заканчивается продуктовый контур и начинается тестовый, перестает быть понятно что можно трогать в рамках тестирования а что нет.
Но отвечая на ваш вопрос: да, это тоже решаемо — эмуляцией такого провайдера своим тестовым.
Разумеется при такой работе придется докручивать еще наборы отдаваемых полей с данными, поскольку они разные у разных поставщиков.
Дело в том что этот проект maglev берется из chromium, из движка v8 и копируется в Node.js как зависимость.
Насколько я понял, сама разработка maglev на стороне Node.js не ведется вообще, его просто копируют из апстрима, поэтому например разница в этом месте между 20й и 22й Node.js очень большая — концов не найти.
Самая главная проблема что уже достаточно давно нет возможности сделать «admin/admin» даже для тестов — теперь все хотят сложные пароли. И разумеется никакой nginx не поможет из‑за CSRF проверок.
Для OAuth/SSO все тоже самое, просто отключение проверки пароля происходит на стороне OAuth сервера, после чего он спокойно авторизует клиентов. Проверено.
Да, я поздно понял что можно было просто переменной окружения пропускать эту проверку :) Но вот все остальное (где про замену файлов) делать не советую.
Node-gyp кстати в моей сборке очень даже работает.
Это отдельная больная тема, разумеется все что касается устаревшего ПО должно работать в закрытых контурах сети, без доступа снаружи.
Понимаю что вам очень хочется обвинить меня в некомпентности, но увы:
Это абсолютно рабочее решение, которое используется уже 10 лет на своих и чужих проектах, которые через нас проходят. И каких-либо проблем до сих пор не было.
Реализация подменяется не в каком-то одном BCryptPasswordEncoder а во всех, включая кастомные (если они присутствуют в проекте)
Так что все с этим проектом хорошо, рекомендую к использованию.
нет, поскольку на этой стадии еще нет загрузки класса - это делает JVM.
Это не сработает в окружении JavaAgent, поскольку код агента отделен от кода приложения - т.е нет import org.springframework.security.PasswordEncoder.
История с профилями заканчивается на моменте использования чужого решения. Врядли получится поиграться с профилями в чужом закрытом проекте, даже если там тоже используется Spring.
Профили это плохо, поскольку у вас начнут отличаться среды выполнения для теста и продакшна. Что означает например возможность получить невоспроизводимые ошибки - на проде есть, на тесте не воспроизводится.
Ну и будут проблемы с библиотеками, которым нужна актуальная версия, будет проблема с node‑gyp и линковкой нативных частей, которых очень много — от sass компилятора и до драйверов к СУБД.
Выложил вот тут: https://filetransfer.io/data-package/zOkMP8uP#link обе сборки.
Потому что устаревший рантайм потянет за собой необходимость сборки с помощью устаревших инструментов, т.е. в данном случае пришлось бы всю разработку целиком проводить на старой версии Node.js.
Также не стоит забывать что речь идет о Node.js, для которой фразы «пожалуйста обновитесь» и «используйте последнюю версию» являются официальным руководством к действию от ее разработчиков, а «обратная совместимость» — грубым ругательством.
Но концептуально вы правы — в большинстве случаев при работе со «средневековыми» версиями действительно приходится разворачивать еще и «средневековую» разработку.
Скорее постепенно убирает слои совместимости, от версии к версии уменьшая возможности по работе устаревшего ПО.
На сегодняшний день для софта уровня DOS/Win3.1/Win95 уже чуть ли не официально рекомендуют использовать Wine или Dosbox вместо того чтобы пытаться запускать в основной ОС.