В итоге, такая идея конструкции сложна технически (чего стоят хитрые омни-колёса со скольжением в поперечной плоскости), но проста математически — двигаться можно тремя колёсами в любом направлении с помощью подбора тяги двух колёс из 3. (Похоже, именно поэтому и понадобились двигатели с управлением по току, что тоже удорожило.) Правда, есть и плюсы — беспроблемная ориентация столика, на котором можно расположить видеокамеру.
Но что, если построить модель движения для более примитивной конструкции, просто трёх жёстких резиновых колёс? Уворачиваться от падения и двигаться придётся более хитрым механизмом «взбирания на гору круговым движением» двух и подтормаживанием одного, самого верхнего из колёс. Заставлять двигаться шар тоже придётся не простым качением тягловых «нижне-передних» колёс «в гору», а движением по правому или левому склону шара, постоянно подбираясь к его вершине сбоку, дозированно тормозя верхним колесом. При этом верхний столик (и всё тело) неизбежно требовал бы вращения. И тогда, чтобы стабилизировать на нём камеру, придётся ставить верхний поворотный двигатель.
Наверняка, в обеих проектах такая идея прорабатывалась и даже уравнения движений, наверное, написаны (и модель в матлабе есть?). Скажите, (автор изделия,) что сложного возникает по пути реализации этой идеи (с упрощением механики)? Может быть, неустойчивость траектории? Может быть, всё равно нельзя отказаться от контроля тяги?
Ряд улучшений редактора и других полей ввода есть в HabrAjax. В частности, высота окошка — в 80% от окна при росте от вводимого текста (максимум), но вручную можно увеличить или уменьшить, потянув за уголок.
А ещё редакторы Гиктаймс очень в курсе. (И значков для них нет, вот где недоработка.) )
И ещё тролли и тролли-легенды очень хорошо знают про минусования, поэтому им нужно делегировать функции удвоенного и утроенного минусования.
Ну, это слабее более ранней концепции некоторых товарищей от 2011 года. Тут нет масштабирования перевозок путём соединения однородных модулей. Но есть масштабирование техобслуживания, что уже хорошо.
В этом плане с вашим проектом хорошо пересекается ещё одна интересная и потенциально нужная как открытый проект задача — индивидуальная раскладка клавиатуры, носимая с собой, не зависящая от ОС. От такой «раскладки» требуется не только перекодировка комбинаций с обычной клавиатуры через USB-переходник, но и кодирование произвольных длинных слов (тех же паролей, но и не только) из других слов или сочетаний клавиш. И там тоже стоит вопрос об аппаратной реализации хаба USB. Так что можно брать вашу реализацию за основу и тащить туда.
Модулярность — это не то. Ангуляр модулярный, но жёсткий по структуре. А есть ли либы с единым JS, но примерно как Backbone по отношению к Ангуляру, Ember, ExtJS, и многим другим?
А не подскажут ли знающие, что лучше Метеора и других full-stack (или тут ещё одно слово-сининим вкручивают — консистентных, что ли) сред программирования на JS? Где максимально избавились от фреймворковости?
Хотелось бы услышать стандартное — зависимости инструментария от ненадёжных факторов — наличия интернета и доступности сервисов Гугла в интернете.
https://www.gstatic.com/charts/loader.js, вроде бы, не имеет ссылок на дальнейшую загрузку чего-либо из интернета. Но зачем-то имеет в себе строку «https://www.gstatic.com/charts». Не используется ли она в вызовах зависимостей?
А как дела с этим в https://www.google.com/jsapi?
Если что — бублики с дырками умеют рисовать amcharts.js без зависимостей. Другие инструменты тоже могут понаходиться в независимых от интернета источниках.
Приложение должно хранить шаблон письма-отклика, с которым пользователь обращается к работодателю. В скрипте этот текстовый шаблон копируется вручную в браузер и хранится в localStorage.
Вопрос: может ли API предоставить память на сервере для хранения этого шаблона (или вообще память) на основе токена пользователя? Тогда оно было бы полезно тем, что в каждый новый браузер пользователь не пришлось бы вводить шаблон.
Далее, второй вопрос: зачем сделана двухэтажная паролизация? Надо сначала войти на страницу выдачи токена под своим паролем, а затем начать пользоваться токеном. Понятно, что так защищается пароль от его постоянного использования. Но можно ли иметь запрос API? который по паролю один раз выдаст токен?
Ага, "… просто скажите себе: «перчатки»." Т.е. написать полезно, но лучше сделать это предельно лаконично: таблица переводов, функции экспозиции, таблица результатов. в одну JS-страницу поместятся с localStorage, даже сервер и интернет не обязателен.
Если посмотреть «Разное», то там — Записывайтесь на новый онлайн-курс от Mail.Ru, Что означает возвращение Мегамозга, Вебинар от «Лаборатории", Стагнация на мобильном рынке,… тоже мусор.
Но что, если построить модель движения для более примитивной конструкции, просто трёх жёстких резиновых колёс? Уворачиваться от падения и двигаться придётся более хитрым механизмом «взбирания на гору круговым движением» двух и подтормаживанием одного, самого верхнего из колёс. Заставлять двигаться шар тоже придётся не простым качением тягловых «нижне-передних» колёс «в гору», а движением по правому или левому склону шара, постоянно подбираясь к его вершине сбоку, дозированно тормозя верхним колесом. При этом верхний столик (и всё тело) неизбежно требовал бы вращения. И тогда, чтобы стабилизировать на нём камеру, придётся ставить верхний поворотный двигатель.
Наверняка, в обеих проектах такая идея прорабатывалась и даже уравнения движений, наверное, написаны (и модель в матлабе есть?). Скажите, (автор изделия,) что сложного возникает по пути реализации этой идеи (с упрощением механики)? Может быть, неустойчивость траектории? Может быть, всё равно нельзя отказаться от контроля тяги?
Итан, Вы? Перелогиньтесь!
И ещё тролли и тролли-легенды очень хорошо знают про минусования, поэтому им нужно делегировать функции удвоенного и утроенного минусования.
Ну, это слабее более ранней концепции некоторых товарищей от 2011 года. Тут нет масштабирования перевозок путём соединения однородных модулей. Но есть масштабирование техобслуживания, что уже хорошо.
(Куда? Не задавался давно этим вопросом; может, кто-то подскажет? Нашёл только похожую функцию в одном гаджете для планшетов — клавиатура через USB)
https://www.gstatic.com/charts/loader.js, вроде бы, не имеет ссылок на дальнейшую загрузку чего-либо из интернета. Но зачем-то имеет в себе строку «https://www.gstatic.com/charts». Не используется ли она в вызовах зависимостей?
А как дела с этим в https://www.google.com/jsapi?
Если что — бублики с дырками умеют рисовать amcharts.js без зависимостей. Другие инструменты тоже могут понаходиться в независимых от интернета источниках.
—Женщину в спортивной одежде, очень быстро бегущую.
Приложение должно хранить шаблон письма-отклика, с которым пользователь обращается к работодателю. В скрипте этот текстовый шаблон копируется вручную в браузер и хранится в localStorage.
Вопрос: может ли API предоставить память на сервере для хранения этого шаблона (или вообще память) на основе токена пользователя? Тогда оно было бы полезно тем, что в каждый новый браузер пользователь не пришлось бы вводить шаблон.
Далее, второй вопрос: зачем сделана двухэтажная паролизация? Надо сначала войти на страницу выдачи токена под своим паролем, а затем начать пользоваться токеном. Понятно, что так защищается пароль от его постоянного использования. Но можно ли иметь запрос API? который по паролю один раз выдаст токен?
Скоро и обезьян научат спутники делать.
Это козы лежали в шезлонгах? Или как они спят?