Если можно, небольшое замечание автору по представлению графиков.
Как мне кажется, для графиков с логарифмическими шкалами лучше всё-таки подписи значений приводить обратно к понятным величинам. Это делает их более читаемыми.
Вот пример этого изменения на одном из ваших графиков:
Однако, согласитесь, что если выбор есть, разумно закладываться на один язык, одну кодовую базу и, одну среду.
По поводу одного языка и одной кодовой базы ничего говорить не буду — случаи могут быть разные, надо смотреть на конкретную ситуацию. Однако, однозначно не могу согласиться с утверждением по поводу одной среды. А если среда перестанет развиваться, или вам нужно будет перейти на платформу, которую данная среда не поддерживает?
Я наоборот стараюсь в своих проектах писать код так, чтобы минимизировать потенциальное количество работы по переходу между платформами (даже, если я этого делать не планирую).
В нашем случае, например, это Delphi + JS, с разными языками и средами работают разные люди.
Так мой изначальный пример как раз про ситуацию, когда одному человеку приходится работать в двух средах одновременно.
это вообще никак не вытекает из моей логики :)
Как я понял, по вашей логике, нужно писать на Delphi ;)
Не всегда есть изначальная возможность что-либо выбирать.
Кроме того, язык программирования следует выбирать исходя из задачи, которую надо решить, а не из того, на чём написаны смежные инструменты.
Следуя вашей логике, все браузеры нужно писать на js или php, потому что они взаимодействуют с кодом на этих языках.
Hardware — реализация это круто. Мой проект изначально тоже задумывался как хардварная реализация.
Идея была тогда выдрать микросхему из старой клавиатуры, сделать девайс с 4-5 кнопками, которые бы закорачивали соответствующие контакты на микросхеме и симулировали таким образом нажатия. Был бы такой пультик управления дебаггером.
Однако, когда начал более-менее серьёзно что-то делать, решил, что програмную реализацию будет сделать попроще всё-таки, да и возможностей у неё будет побольше. А вырванная микросхемка, у меня до сих пор где-то в шкафу валяется.
При обычной работе в IDE я использую конфигурацию, похожую на ту, которая у меня лежит в примерах. Немного её переделал, но идея та же. Там для каждого из режимов работы есть по странице с 4-8 кнопками.
Во время работы, страница с соответствующим режимом отрыта на телефоне и всё время перед глазами (телефон на подставке, поэтому брать в руки его обычно не надо). Поэтому, чаще всего, нужное действие можно выполнить в один тап по экрану телефона.
Вот, как выглядят эти страницы на телефоне для этой конфигурации
Для отладки телефон берётся в руку и кнопки пошагового исполнения нажимаются большим пальцем не глядя (обратите внимание, как они разнесены пространственно по экрану, — это гарантирует, что я не промахнусь и не нажму не на ту кнопку). Поскольку во время пошаговой отладки основное внимание уделяется происходящему на экране, а печатать на клавиатуре особо не нужно, то этот подход для меня работает нормально.
Кроме того, я использую систему в качестве ассистента во время набора текста (вещи, похожие на те примеры, которые приведены в конце статьи).
Естественно, исторически сложившиеся тенденции переломить очень сложно. Но у них и в сравнительно недавно появившихся вещах разброд и шатание. Вон, в VS до сих пор ctrl+click не добавили из коробки.
Так можно переписать серверную часть на java и использовать везде eclipse. Тоже решит проблему, а переписывать придётся только половину проекта, а не всё целиком.
Пример про VS и eclipse я привёл в статье просто как самый очевидный.
Если бы всё ограничивалось только тремя командами дебаггера, то, конечно, я бы не стал заморачиваться.
По-моему, у этой системы область применения может быть гораздо шире, чем только те примеры, которые я привёл.
Когда я начинал писать этот проект, я попробовал поискать информацию о том, как это сделать, но толком ничего не нашёл.
Кроме того, все эмуляторы трэкпадов на google play, которые я нашёл, используют серверную часть. Поэтому, я решил не морочить голову.
Если у кого-нибудь есть пример, как можно заставить телефон притвориться bluetooth клавиатурой или мышью для внешнего устройства, буду очень рад ссылке.
Про MOUSE4, MOUSE5, — это не должно быть проблемой в реализации и сейчас. Robot вроде как это всё поддерживает.
Иногда, когда просыпается мой внутренний конспиролог, мне кажется, что производители ПО делают это намеренно, чтобы усложнить миграцию для пользователей (см. вторую проблему в начале моей статьи).
Вообще, наверно вы правы. Функциональность, позволяющая отправлять с сервера на клиент битмапы не усложняет работу с библиотекой тем пользователям, которым это не нужно. А те, кому эта функциональность необходима, сами решат, как генерировать битмапы на их стороне.
Про 3D не совсем понял. Вы имеете ввиду рендеринг 3D сцены в буфер в памяти и отправку этого буфера как картинки на клиент?
По-моему, основная проблема с «ручным» созданием layout — отсутствие документации. Я надеюсь, что после её добавления, будет проще в этом разобраться. Конечно, графический конструктор более интуитивен, но пока что для меня он не в приоритете.
Спасибо, что обратили моё внимание на сенсоры. Возможно, реализация доступа к сенсорам устройства — одна из самых важных фич подобных систем сопряжения телефона с компьютером.
По части генерации интерфейса множеством атомарных сигналов, я опасался, что этот подход приведёт к тому, что будет тяжело на серверной стороне поддерживать актуальное представление состояния на клиенте. Что, в свою очередь, усложняет дальнейшие изменения сцены на клиенте.
Не возникает ли у вас такая проблема?
Спасибо за слова поддержки.
Одной из мотиваций к написанию мной данной статьи была возможность получить информацию об уже существующих системах с аналогичным подходом.
Философия вашего проекта, насколько я могу судить, схожа с моей — позволить пользователю максимально абстрагироваться от сетевой инфраструктуры и писать свою программу так, как будто это обычное десктопное приложение с UI.
Как мне кажется, для графиков с логарифмическими шкалами лучше всё-таки подписи значений приводить обратно к понятным величинам. Это делает их более читаемыми.
Вот пример этого изменения на одном из ваших графиков:
Я наоборот стараюсь в своих проектах писать код так, чтобы минимизировать потенциальное количество работы по переходу между платформами (даже, если я этого делать не планирую).
Так мой изначальный пример как раз про ситуацию, когда одному человеку приходится работать в двух средах одновременно.
Как я понял, по вашей логике, нужно писать на Delphi ;)
Кроме того, язык программирования следует выбирать исходя из задачи, которую надо решить, а не из того, на чём написаны смежные инструменты.
Следуя вашей логике, все браузеры нужно писать на js или php, потому что они взаимодействуют с кодом на этих языках.
На счёт мышки — я лично не люблю блуждать по менюшкам (но это уже во многом дело вкуса).
Идея была тогда выдрать микросхему из старой клавиатуры, сделать девайс с 4-5 кнопками, которые бы закорачивали соответствующие контакты на микросхеме и симулировали таким образом нажатия. Был бы такой пультик управления дебаггером.
Однако, когда начал более-менее серьёзно что-то делать, решил, что програмную реализацию будет сделать попроще всё-таки, да и возможностей у неё будет побольше.
А вырванная микросхемка, у меня до сих пор где-то в шкафу валяется.Во время работы, страница с соответствующим режимом отрыта на телефоне и всё время перед глазами (телефон на подставке, поэтому брать в руки его обычно не надо). Поэтому, чаще всего, нужное действие можно выполнить в один тап по экрану телефона.
Для отладки телефон берётся в руку и кнопки пошагового исполнения нажимаются большим пальцем не глядя (обратите внимание, как они разнесены пространственно по экрану, — это гарантирует, что я не промахнусь и не нажму не на ту кнопку). Поскольку во время пошаговой отладки основное внимание уделяется происходящему на экране, а печатать на клавиатуре особо не нужно, то этот подход для меня работает нормально.
Кроме того, я использую систему в качестве ассистента во время набора текста (вещи, похожие на те примеры, которые приведены в конце статьи).
Пример про VS и eclipse я привёл в статье просто как самый очевидный.
По-моему, у этой системы область применения может быть гораздо шире, чем только те примеры, которые я привёл.
Вот список того, что я нашёл. Все проекты ниже пытаются решить схожие задачи:
Кроме того, все эмуляторы трэкпадов на google play, которые я нашёл, используют серверную часть. Поэтому, я решил не морочить голову.
Если у кого-нибудь есть пример, как можно заставить телефон притвориться bluetooth клавиатурой или мышью для внешнего устройства, буду очень рад ссылке.
Про MOUSE4, MOUSE5, — это не должно быть проблемой в реализации и сейчас. Robot вроде как это всё поддерживает.
Про 3D не совсем понял. Вы имеете ввиду рендеринг 3D сцены в буфер в памяти и отправку этого буфера как картинки на клиент?
Спасибо, что обратили моё внимание на сенсоры. Возможно, реализация доступа к сенсорам устройства — одна из самых важных фич подобных систем сопряжения телефона с компьютером.
Не возникает ли у вас такая проблема?
Одной из мотиваций к написанию мной данной статьи была возможность получить информацию об уже существующих системах с аналогичным подходом.
Философия вашего проекта, насколько я могу судить, схожа с моей — позволить пользователю максимально абстрагироваться от сетевой инфраструктуры и писать свою программу так, как будто это обычное десктопное приложение с UI.