В статье не затронута и малая часть функциональных пряников, которые в избытке имеются в продуктах jetbrains. Англоязычные статьи и скринкасты на порядок информативнее.
Можно прямо брать все подряд туториалы из блога blog.jetbrains.com/webide/ и переводить сюда.
А на самом деле, во истину гениальная идея — прессовать снег в кирпичи! В таком виде его и хранить удобно, и даже использовать для каких-нибудь целей. Да хоть крепость детям во дворе построить ледяную :)
С той скоростью, что он носится, с гусицами легко могут случиться проблемы :) У пневматиков сопротивление качению ниже, да и крутиться можно резвее — гусеница слетает охотнее покрышки.
Гусеничный ход используют для уменьшения давления на грунт. Этот же агрегат передвигается преимущсетвенно по твердому грунту. Да и цены на гусеницы обычно на порядок выше.
На современных авто возможно, мне кажется. Но я не знаю, как устроена электроника в напичканном авто. Чисто теоретически — рулить умеет, газ электронный, вместо селектора АКПП — джойстик.
Вот неплохая статья про перехват сигналки: www.autoreview.ru/archive/2006/21/ugon/
Сейчас протоколы шифрования достаточно сложные для анализа и подбора ключей. Глушилки сигнала ставят, да, но они рассчитаны на невнимательного водителя, который нажал кнопку и пошел, не проверив постановку на охрану. А угоняют авто, подменяя блок управления двигателем на свой, и своим же ключом заводят, и уезжают.
Обычно на электроцепи двигателя для этих целей ставится защита (иммобилайзер), чтобы невозможно было завести двигатель без ключа. Но всякого рода системы дистанционного запуска внедряются в оригинальные цепи (порой даже путем хранения ключа в машине и вставке своего иммобилайзера). Без физического вмешательства просто так взять и увести машину не получится, если только по глупости собственика и/или установщиков сигнализации.
Вот HUD — без пробем (чтение данных), а интеграция в существующие цепи и логиу работы — очень вряд ли. По крайней мере, не без серьезного вмешательства в другие системы.
В большинстве случаев контур управления системами отделен от индикации и телеметрии. В том же фокусе по отдельному контроллеру на водительскую дверь, щиток приборов, модуль управления двигателем и т.д.
Чуть выше уже ответил. Но, похоже, что проприетарные протоколы будут оставаться проприетарными. А необходимые функции по переводу в открытый API будет осуществлять контроллер. Прошивку производители раскрывать не обязаны :)
Updates to the CAN translator firmware may be distributed as pre-compiled binaries, e.g. if they are distributed by an OEM who does not wish to make the CAN signals public
Похоже, что ELM выполняет всего часть из возложенных на CAN Translator функций, а именно, преобразование OBD в RS232. CAN транслятор же содержит в себе «переводчик» проприетарных инструкций, в открытый API.
Выдержка с официального сайта:
The exact format of these bit fields and messages are typically considered sensitive information by vehicle manufacturers. The OpenXC CAN translator allows these companies to keep that information private, but still give consumers and developers access to the data contained within.
При использовании elm эту задачу на себя берет ПО.
Мощности, видимо, в избытке. По видео ощущение, что он очень легкий. И любопытно, есть ли какая-либо стабилизация движения? При крутом угле отвала его должно прилично тянуть в сторону на толстом слое мокрого снега.
Очень не хватает примеров. Это ведь самое главное.
Спросите, кто не знает про ТТД? Большинство в какой-то мере слышали и пробовали. Но мало кто действительно применяет ТТД на практике, потому что в голове не укладывается, как перевернуть стандартный процесс с ног на голову. На переучивание уходит много времени, которое, чаще всего, не оплачивается :) Мало того, что нужно держать в голове будущую архитектуру, так еще и владеть написанием тестов в совершенстве.
ТТД даёт большое преимущество в долгосрочной перспективе, когда проект уже выбрался из песочницы и имеет хотя бы ядро с устоявшейся архитектурой. На моём личном опыте затраты на создание окружения для тестирования на начальном этапе занимает очень много времени. Создание начального прототипа проекта очень итерационный процесс, когда ты еще только планируешь, как будешь решать поставленную задачу. И к каждой итерации по написанию кода добавляется пара итераций по написанию тестов — спроектировать тесты + написать тесты.
Спасибо за великолепно написанную статью!
Несмотря на формулы и математические выдержки, читается на одном дыхании! В отличие от материалов по ссылкам :)
Кинематика вообще в большинстве своем завораживает. Будь то паровозный привод или шагающий механизм. Да даже съемки работающей подвески автомобиля.
И вопрос напоследок: а как добиться минимального количества звеньев? Даже прямая дается большим количеством при аппроксимировании 1.
С точки зрения конструкции и технологий намного более интересно смотрятся проекты Festo, год назад про их робота-чайку на хабре упоминали. У них довольно интересные ролики про процесс создания их роботов. А эта стрекоза скорее напоминает студенческий проект или хобби.
Что касается Redmine, то в post-commit хуке можно его дергать, чтобы обновлялся кэш. Это удобно, например, для автоматической привязки коммитов к задачам (wiki).
Я имел ввиду хуки на сервере, подразумевая, что сервер и устройство находятся в непосредственной близости. Если вам нужно получать информацию не на сервере — можно складывать события в базу, в очередь, в отдельный файл и т.п., чтобы на заниматься парсингом лишний раз.
Что касается клиента — можно было бы помимо парсинга использовать, например, модуль svn и дёргать svn_log с лимитом.
Скажите пожалуйста, вы специально обошли стороной стандартный механизм хуков svn для получения данных о коммитах? Как-то громоздко выглядит curl и парсинг раз в минуту веб-морды для svn, когда можно в post-commit записать одну-единственную строчку с вызовом бикалки. Получится практически real-time информирование.
Более того, при использовании проверок в pre-commit, фейлы можно обозначать какой-нибудь сиреной и выводить на светодиодное табло логин провинившегося :)
Еще можно подумать в сторону использования BlueTooth, ZigBee или других беспроводных технологий, чтобы отвязать устройство от компьютера.
Насчет 4 пункта — в большинстве секундных клеев используется цианоакрилат. Он, несмотря на страшное название, изначально разрабатывался для медицинских целей. Википедия
Можно прямо брать все подряд туториалы из блога blog.jetbrains.com/webide/ и переводить сюда.
А на самом деле, во истину гениальная идея — прессовать снег в кирпичи! В таком виде его и хранить удобно, и даже использовать для каких-нибудь целей. Да хоть крепость детям во дворе построить ледяную :)
Гусеничный ход используют для уменьшения давления на грунт. Этот же агрегат передвигается преимущсетвенно по твердому грунту. Да и цены на гусеницы обычно на порядок выше.
Вот неплохая статья про перехват сигналки: www.autoreview.ru/archive/2006/21/ugon/
Сейчас протоколы шифрования достаточно сложные для анализа и подбора ключей. Глушилки сигнала ставят, да, но они рассчитаны на невнимательного водителя, который нажал кнопку и пошел, не проверив постановку на охрану. А угоняют авто, подменяя блок управления двигателем на свой, и своим же ключом заводят, и уезжают.
Выдержка с официального сайта:
При использовании elm эту задачу на себя берет ПО.
Мощности, видимо, в избытке. По видео ощущение, что он очень легкий. И любопытно, есть ли какая-либо стабилизация движения? При крутом угле отвала его должно прилично тянуть в сторону на толстом слое мокрого снега.
Спросите, кто не знает про ТТД? Большинство в какой-то мере слышали и пробовали. Но мало кто действительно применяет ТТД на практике, потому что в голове не укладывается, как перевернуть стандартный процесс с ног на голову. На переучивание уходит много времени, которое, чаще всего, не оплачивается :) Мало того, что нужно держать в голове будущую архитектуру, так еще и владеть написанием тестов в совершенстве.
ТТД даёт большое преимущество в долгосрочной перспективе, когда проект уже выбрался из песочницы и имеет хотя бы ядро с устоявшейся архитектурой. На моём личном опыте затраты на создание окружения для тестирования на начальном этапе занимает очень много времени. Создание начального прототипа проекта очень итерационный процесс, когда ты еще только планируешь, как будешь решать поставленную задачу. И к каждой итерации по написанию кода добавляется пара итераций по написанию тестов — спроектировать тесты + написать тесты.
Несмотря на формулы и математические выдержки, читается на одном дыхании! В отличие от материалов по ссылкам :)
Кинематика вообще в большинстве своем завораживает. Будь то паровозный привод или шагающий механизм. Да даже съемки работающей подвески автомобиля.
И вопрос напоследок: а как добиться минимального количества звеньев? Даже прямая дается большим количеством при аппроксимировании 1.
Что касается клиента — можно было бы помимо парсинга использовать, например, модуль svn и дёргать svn_log с лимитом.
Более того, при использовании проверок в pre-commit, фейлы можно обозначать какой-нибудь сиреной и выводить на светодиодное табло логин провинившегося :)
Еще можно подумать в сторону использования BlueTooth, ZigBee или других беспроводных технологий, чтобы отвязать устройство от компьютера.