Cordova — замечательный инструмент, у которого, впрочем, есть свои ограничения.
Во-первых, очень плохо с отладкой. Если вы допустили ошибку в JS-коде, приложение молча перестает работать. Понять что происходит можно только со строгой дисциплиной — одно изменение в коде, затем проверка. Еще помогает перед запуском пропустить код через JSLint, он ловит синтаксические ошибки.
Я знаю, что можно запустить код в браузере. Однако, и это во-вторых, не все плагины работают в режиме браузера. Так, например, не работает SQLite, поэтому тестирование можно осуществлять только на реальном устройстве или в эмуляторе, что не очень удобно. Кроме того, в некоторых случаях незначительно различается поведение кода на эмуляторе и на устройстве, также местами различается результат верстки HTML.
Поэтому выбирать Cordova для относительно сложных приложений, требующих чего-то большего, чем просто HTML+JS, нужно с осторожностью.
Не буду оспаривать ваши замечания — я пользовался ErgoEmacs продолжительное время.
Есть вещи, которые кажутся удобными, а есть удобные. Вот ErgoEmacs претендует на удобство, но, по сути, не предоставляет его.
В ситуации, когда есть необходимость мигрировать между большим количеством компьютеров, ОС, сред и т.д., не все из которых ты можешь настраивать, проще держать минимальную конфигурацию (разных) Emacs и пользоваться ей.
Лисп практически во всех своих инкарнациях — очень гибкий язык, и в этом его сложность. Лисп может быть такой, какой нужен программисту. В нем (особенно это верно для Common Lisp) можно работать в любой программной парадигме: процедурное программирование, ООП, функциональное программирование, аспектно-ориентированное программирование, декларативное программирование и т.д. Систему макросов так вообще еще никто не догнал и вряд ли догонит.
Многие программные продукты появляются сначала на Лиспе в качестве proof of concept, а затем уже переписываются на чем-то другом (см., например, Montezuma). Его рыночная ниша действительно небольшая. Но это и не нужно, т.к. далеко не всегда нужна подобная гибкость. Зачастую лучше взять инструмент попроще.
Что касается собственно ErgoEmacs, то это скорее вредный продукт. Я им пользовался продолжительное время (что-то около полугода), но потом вернулся на классическую раскладку и ничуть не жалею.
Во-первых, Emacs, как правило, везде настроен одинаково в смысле клавиатурных сокращений и не всегда есть возможность использовать свой конфиг.
Во-вторых, и это более значительный факт, большинство пакетов, которые ставятся в Emacs неявно предполагают наличие классической раскладки, т.е. несколько раз у меня было, что в ErgoEmacs пакеты просто отказывались работать из-за клавиш.
Ну и последнее, раз уж автор упомянул работу с эргономичной клавиатурой. Я достаточно долго уже использую раскладку Dvorak в паре с эргономичной клавиатурой (TypeMatrix). Если при этом еще использовать ErgoEmacs, то клавиши приходится в уме переводить дважды, сначала с Dvorak, затем с ErgoEmacs. Получилось слишком уж мудрено.
В итоге я вернулся на классический Emacs, постепенно выстраиваю его под себя, а разрекламированный ErgoEmacs снес и больше не вспоминаю.
Согласен, не все одназначно.
Сам участвовал в разработке/внедрении/выводе из эксплуатации не одного десятка систем и знаю, что такие самописанные системы могут быть узким местом. Но также знаю и то, что крупные enterprise-системы не могут учесть всех тех тонкостей, которые есть у пользователей на местах. Здесь же программы из небольшой наколенной разработки выросли до зрелой системы, да еще и без особого содействия со стороны автора.
Меня поразило именно это — попадание программиста в потребность и то, что инструмент удался.
Одна — весьма специфичный инструмент по учету неисправностей в электрооборудовании, раскиданном на большом расстоянии, другая — своеобразный органайзер, позволяющий собрать в одно время большое количество народа, также находящегося на большом расстоянии.
Насколько я понимаю, вопрос этот скорее исторический, нежели практический.
Тексты то печатались на машинке, отсюда и интерлиньяж, ну а шрифт — то что в Word'e приемлимое было, на том и привыкли делать.
По моим наблюдениям, впрочем, ситуация потихоньку меняется — ВУЗы начинают свои стандарты разрабатывать, не такие «дурные».
Если это утверждение, то — не лень.
Некоторые сложности на входе, зато в дальнейшей верстке куча вопросов снимается.
Особенно удобно местами менять приложения и работать со ссылками.
Это большая и важная работа. Без IDE многим работать сложно, и такие штуки сильно упрощают жизнь, да.
Что, простите? Не понял вопрос.
Очень интересные результаты!
Несколько вопросов:
Можно ли не вращать пользователя, если поставить 4-6 стационарных камеры?
Можно ли вообще комбинировать съёмки с нескольких камер?
Какое расстояние требует RealSence? Kinect?
Выходная модель пользователя размечена (выступающая точка живота, линия бёдер, колено, локоть и т. д.) или набор метрики вшит в SDK?
Считаете на устройстве или в облаке?
Существует вариант SDK на десктопе?
Во-первых, очень плохо с отладкой. Если вы допустили ошибку в JS-коде, приложение молча перестает работать. Понять что происходит можно только со строгой дисциплиной — одно изменение в коде, затем проверка. Еще помогает перед запуском пропустить код через JSLint, он ловит синтаксические ошибки.
Я знаю, что можно запустить код в браузере. Однако, и это во-вторых, не все плагины работают в режиме браузера. Так, например, не работает SQLite, поэтому тестирование можно осуществлять только на реальном устройстве или в эмуляторе, что не очень удобно. Кроме того, в некоторых случаях незначительно различается поведение кода на эмуляторе и на устройстве, также местами различается результат верстки HTML.
Поэтому выбирать Cordova для относительно сложных приложений, требующих чего-то большего, чем просто HTML+JS, нужно с осторожностью.
therndguy.com/papers/curves.pdf
Есть вещи, которые кажутся удобными, а есть удобные. Вот ErgoEmacs претендует на удобство, но, по сути, не предоставляет его.
В ситуации, когда есть необходимость мигрировать между большим количеством компьютеров, ОС, сред и т.д., не все из которых ты можешь настраивать, проще держать минимальную конфигурацию (разных) Emacs и пользоваться ей.
Лисп практически во всех своих инкарнациях — очень гибкий язык, и в этом его сложность. Лисп может быть такой, какой нужен программисту. В нем (особенно это верно для Common Lisp) можно работать в любой программной парадигме: процедурное программирование, ООП, функциональное программирование, аспектно-ориентированное программирование, декларативное программирование и т.д. Систему макросов так вообще еще никто не догнал и вряд ли догонит.
Многие программные продукты появляются сначала на Лиспе в качестве proof of concept, а затем уже переписываются на чем-то другом (см., например, Montezuma). Его рыночная ниша действительно небольшая. Но это и не нужно, т.к. далеко не всегда нужна подобная гибкость. Зачастую лучше взять инструмент попроще.
Что касается собственно ErgoEmacs, то это скорее вредный продукт. Я им пользовался продолжительное время (что-то около полугода), но потом вернулся на классическую раскладку и ничуть не жалею.
Во-первых, Emacs, как правило, везде настроен одинаково в смысле клавиатурных сокращений и не всегда есть возможность использовать свой конфиг.
Во-вторых, и это более значительный факт, большинство пакетов, которые ставятся в Emacs неявно предполагают наличие классической раскладки, т.е. несколько раз у меня было, что в ErgoEmacs пакеты просто отказывались работать из-за клавиш.
Ну и последнее, раз уж автор упомянул работу с эргономичной клавиатурой. Я достаточно долго уже использую раскладку Dvorak в паре с эргономичной клавиатурой (TypeMatrix). Если при этом еще использовать ErgoEmacs, то клавиши приходится в уме переводить дважды, сначала с Dvorak, затем с ErgoEmacs. Получилось слишком уж мудрено.
В итоге я вернулся на классический Emacs, постепенно выстраиваю его под себя, а разрекламированный ErgoEmacs снес и больше не вспоминаю.
Вы правы, особенно хороша Let Over Lambda.
PCL, глава 8. Создание собственных макросов
А тут вообще можно недорого разжиться книжкой по Лисп:
ANSI Common Lisp
Во многих случаях можно сравнить вызов (func) в Lisp с вызовом func() в Си. Количество скобок и семантика совпадают :)
Так что все не так страшно.
Скорее можно сказать, что здесь идет пояснение для учеников автомобильного техникума, как именно работает ДВС и как энергия преобразуется в движение.
Т.е. для тех, кто уже знает о существовании comp.lang.lisp и уже что-то попробовал сделать сам.
1. Один из основных сайтов в Рунете, посвященных Lisp:
http://lisper.ru
Там и форум, и агрегатор, и еще много чего.
2. Embedded Qt Lisp
GUI для Lisp (ECL). Интересная библиотека, позволяет строить интерфейс на основе Qt с помощью Lisp (ECL). Довольно активная разработка.
http://password-taxi.at/EQL
Сам участвовал в разработке/внедрении/выводе из эксплуатации не одного десятка систем и знаю, что такие самописанные системы могут быть узким местом. Но также знаю и то, что крупные enterprise-системы не могут учесть всех тех тонкостей, которые есть у пользователей на местах. Здесь же программы из небольшой наколенной разработки выросли до зрелой системы, да еще и без особого содействия со стороны автора.
Меня поразило именно это — попадание программиста в потребность и то, что инструмент удался.
Собственно именно эту мысль и хотел донести. В ситуации с моим приятелем программы писались именно как инструмент, который был нужен для работы.
Тексты то печатались на машинке, отсюда и интерлиньяж, ну а шрифт — то что в Word'e приемлимое было, на том и привыкли делать.
По моим наблюдениям, впрочем, ситуация потихоньку меняется — ВУЗы начинают свои стандарты разрабатывать, не такие «дурные».
Если это утверждение, то — не лень.
Некоторые сложности на входе, зато в дальнейшей верстке куча вопросов снимается.
Особенно удобно местами менять приложения и работать со ссылками.
Весь диплом выложить не могу, много непубличной информации.
Несколько страниц на mail.ru