Отныне я не буду больше создавать нативные приложения. Все мои приложения в дальнейшем будут прогрессивными веб-приложениями (PWA, Progressive Web Apps). Это такие приложения, которые предназначены для еще более органичной работы на мобильных устройствах, чем нативные приложения.

Что я имею ввиду под «более органичной работой»? Большая часть веб-траффика исходит от мобильных устройств и пользователи устанавливают в среднем от 0 до 3 новых приложений в месяц. Это означает, что люди не тратят много времени на поиск новых приложений в App store, но они проводят много времени в сети, где могут найти и использовать ваше приложение.

Прогрессивные веб-приложения начинают свою работу как любое другое веб-приложение, но когда пользователь возвращается в приложение и показывает (фактом использования), что он заинтересован в более регулярном обращении к приложению, браузеры предложат пользователю установить приложение на свой домашний экран. PWA также могут использовать push-уведомления как и нативные приложения.

Переслать роботу на Ардуине несколько байт через вайфай, блютус, последовательный порт или любой другой канал связи в виде команды, а потом принять несколько байт в качестве ответа труда не составляет: достаточно скачать скетч с примером обмена данными «здравствуй мир» и вставить в него несколько строк своего кода, который будет выполнять желаемые действия.

Однако с развитием проекта область вспомогательного кода, который отвечает за связь с внешним миром, раздувается: появляется логика, отделяющая один пакет данных от другого, разрастается лес проверок, что за команда пришла, какие у нее параметры, как её правильно выполнить, что делать, если пакет данных не корректен, если данные пришли не полностью, если они не умещаются в отведенных для них буферах памяти и так далее. Код, обслуживающий вспомогательную логику, переплетается с главным кодом, выполняющим интересную и полезную работу. Заменить один канал связи на другой (например, добавить к последовательному порту вайфай) без переработки накопившейся кодовой базы становится весьма проблематично.

Долгое время я таскал такой код из одного проекта в другой, новые улучшения и исправления приходилось обновлять во всех проектах параллельно. Это утомительно, чревато появлением новых ошибок и не всегда возможно. Наконец пришло время вынести всю эту логику в отдельную библиотеку.

Исходная задача: упростить процесс создания прошивки для роботов, которые будут работать в режиме «вопрос-ответ». Главный скетч должен содержать полезный код (что, собственно, должен делать робот) и минимальное количество вспомогательных конструкций. Все вспомогательные транспортно-протокольные блоки окуклить в библиотеку и вынести за пределы внимания инженера.

В качестве побочного эффекта получилась своеобразная командная строка, работающая внутри Ардуины, если подключиться к ней через монитор последовательного порта и отправлять команды вручную:

Этой статьей мы продолжаем рассказывать о датчиках от швейцарской компании IST. Не так давно были опубликованы посты о датчиках электрической проводимости воды и датчиках скорости потока жидкостей и газов, сегодня очередь дошла до относительной влажности.



Статья посвящена высокоточным датчикам серии HYT. Приводится описание устройства датчика и чувствительного элемента, подробно разбирается порядок сопряжения датчика с микроконтроллером, приводится пример разработки.

По работе я занимаюсь разработкой алгоритмов обработки изображений и в частности алгоритмами автоматического слежения за объектами на видео для специального применения. Недавно понадобилось сделать модель алгоритма, управляемую с удаленного компьютера для отладки логики работы в сложной системе. Раньше такая задача не стояла, т.к. все алгоритмы реализовывались в итоге на FPGA. Давно работаю с OpenCV и, потерев руки, подошел к написанию программы. Но энтузиазм быстро погас, когда столкнулся непосредственно с передачей видео по сети.

Задача заключалась в следующем:

1. Написать программу сервер, которая загружает видео из файла, сжимает в JPEG и передает по протоколу TCP программе клиенту.
2. Написать программу клиент, которая принимает видео по TCP, декодирует и отображает.

В сборках GCC под windows (cygwin,mingw) из коробки нет удобного макроса __try{} __except{} для перехвата как программных (throw MyExc) так и системных (сигналы). Попробуем изобрести свой велосипед.

Вся статья в 3-х пунктах:

1. Создаём try catch блок
2. Оборачиваем его в SEH блок
3. Когда SEH поймает исключение, бросаем программное исключение

Если заинтересовал, добро пожаловать под кат.

Если вы планируете поездку и уже нашли недорогой перелет, не спешите покупать билеты, потому что сейчас вы найдете билеты еще дешевле. И это не реклама очередного говноагрегатора.

Всем известно, что авиакомпании берут свои цены с потолка. Маркетологи придумывают хитроумные непрозрачные схемы отъёма денег у пассажиров пропорционально финансовым возможностям последних. Так, чтобы богатые платили за билеты побольше, а бедные — сколько смогут.

Привет Хабр! Я опубликовал уже три части из цикла статей (раз, два, три), а тут часть 0, как снег на голову. Как же так? Всё дело в том, что виртуализация является опциональной при построении нашего хостинга. Эта статья — самодостаточна, она не связана с другими частями из цикла. Вы вообще можете их не читать, если просто хотите разделить ваш выделенный сервер на несколько виртуальных машин.

Всё что я буду рассказывать может выполнить обычный программист в течение 5 минут, просто запустив набор сценариев для Ansible, которые я подготовил специально для вас и выложил на GitHub.

Приветствую хабрасообщество!

Не так давно мне в руки попала отладочная плата STM32F429I-DISCO на базе контроллера STM32F429ZI.
Пожалуй главной ее отличительно особенностью является помимо достаточно производительного процессора Cortex M4 — интегрированный экран на 2,4'' дюйма, которого вполне хватает для многих экспериментов.
Первым делом я естественно начал искать по нему документацию и примеры. Хорошая документация вместе с примерами нашлась прямо на сайта st.com, но естественно хотелось большего, туториалов и прочего. То чего так не хватает начинающему программисту под ARM. Но детальный поиск не дал каких то больших результатов. Поэтому пришлось собирать информацию по крохам, анализировать, пересматривать и тестировать ее.

И я решил как то попробовать поспособствовать популяризации данной удобной платформы.
Но данный пост не призван решить какие то всеобъемлющие проблемы, он ориентирован безусловно на начинающих и на тех, кто хотел бы попробовать, но считает, что это слишком сложно.

Тем кому это может показаться интересным, добро пожаловать под кат.

Приветствую!

Хочу поделиться собственным опытом разработки электронного устройства. Сначала расскажу небольшую предысторию, чтобы было понятно, зачем это, собственно, нужно было мне.

С чего все начиналось

Изначально мы занимались разработкой программного обеспечения для чип-тюнинга. Одна из основных задач которого — считать прошивку из ЭБУ (электронный блок управления двигателем) и записать ее обратно. Понятное дело, что для этих целей нужно каким-то образом связать компьютер и ЭБУ при помощи адаптера. Когда раньше подавляющее количество ЭБУ использовало простейший способ приема-передачи данных, достаточно было использовать простейший адаптер на транзисторах или специализированной микросхеме. Однако на сегодняшний день большинство автомобилей для «общения» своих компонентов со внешней средой используют CAN шину. Адаптер для CAN шины на транзисторах уже не соберешь, и тут однозначно нужен процессор, который будет управлять всем по определенной программе.
Так возникла первая проблема — как побороть CAN шину. Для того, чтобы не изобретать велосипед выбор сделан на использовании готового адаптера, который работает по стандарту J2534. Для тех, кто не в курсе, стандарт J2534 это стандарт, описывающий аппаратную и программную части устройства, с помощью которого можно произвести подключение к ЭБУ посредством компьютера. Разработали его американцы. Основной причиной его разработки стало законодательное закрепление возможности обновление прошивки ЭБУ не специализированным дилерским сервисом, а любым желающим. Собственно, если каждый желающий может обновить прошивку на своем телефоне, то почему он не может это сделать со своим автомобилем.

Самый доступный импортный аналог стоит в районе 200 долл. США. Как впоследствии оказалось, два одинаковых устройства, удовлетворяющие стандарту J2534, могут работать по-разному с одним и тем же программным обеспечением. Поэтому изначально пришлось привязаться к конкретному производителю и его устройству.

Первая статья цикла: 1-Wire slave на МК. Часть 1: Железо

Что есть в инетрнете по 1-Wire slave

В интернете про реализацию 1-Wire мастера можно найти множество информации, статей, application notes для микроконтроллеров на любой вкус и цвет.
А вот для реализации со стороны Slave материалов немного. Исходных кодов и того меньше. В итоге был найден один исходник для PIC, с ассемблерными вставками и ошибками. Недавно появилась статья на хабре для MSP430 от resetnow. Под катом наш вариант реализации задачи.

Сейчас для многих компьютерное зрение не является тайной за семью замками. Однако новые алгоритмы и подходы не перестают впечатлять. Одним из таких направлений является монокулярное зрение, в особенности SLAM. О том, как мы решали задачу навигации квадрокоптера, оснащенного единственной камерой, и пойдет речь в этой статье.

На днях в Минске состоится выставка новых устройств, созданных в рамках белорусских железячных стартапов — Party Hard! 2016. Мы решили рассказать об одном из самых интересных экспонатов этой выставки — умном дозиметре ZIVE, который синхронизируется со смартфоном и собирает данные для глобальной карты радиационного загрязнения.

abstract: В статье описаны продвинутые функций OpenSSH, которые позволяют сильно упростить жизнь системным администраторам и программистам, которые не боятся шелла. В отличие от большинства руководств, которые кроме ключей и -L/D/R опций ничего не описывают, я попытался собрать все интересные фичи и удобства, которые с собой несёт ssh.

Предупреждение: пост очень объёмный, но для удобства использования я решил не резать его на части.

Оглавление:

• управление ключами
• копирование файлов через ssh
• Проброс потоков ввода/вывода
• Монтирование удалённой FS через ssh
• Удалённое исполнение кода
• Алиасы и опции для подключений в .ssh/config
• Опции по-умолчанию
• Проброс X-сервера
• ssh в качестве socks-proxy
• Проброс портов — прямой и обратный
• Реверс-сокс-прокси
• туннелирование L2/L3 трафика
• Проброс агента авторизации
• Туннелирование ssh через ssh сквозь недоверенный сервер (с большой вероятностью вы этого не знаете)

Иногда полезно окинуть взглядом историю развития технологий, чтобы переосмыслить некоторые подходы к собственным разработкам. Сегодня мы решили взглянуть на то, что ждет Интеренет с точки зрения развития в ближайшем будущем.

Вы — разработчик мобильного приложения, и вы очень гордитесь собой, поскольку только что закончили работу над очередной отличной программой. В нее добавлены все функции, которые могут быть полезны пользователю. Программа многократно протестирована, все работает отлично. Вы приняли работу дизайнера, который создал симпатичные иконки и прочие изображения. Загружаем приложение в каталог и… через несколько дней видим огромное количество удалений вашего приложения пользователями, которые его уже установили.

Они не просто не используют вашу программу, нет, они ее удаляют! Но почему? Вы запускаете приложение и начинаете его тестировать, изучать снова и снова, выискивая возможную проблему. Но все работает отлично, явных причин нет. В чем же дело? Давайте попробуем разобраться.

У восстановленного с завода Thinkpad с предустановленной Windows 7 в планировщике есть приложение, которое включается раз в день и собирает данные о том, как вы используете компьютер. После этого все сведения отправляются компании-аналитику. Информация о сборе данных присутствует в пользовательском соглашении, но зарыта очень глубоко.

Ради одного из своих небольших проектов на Raspberry Pi 2 я приобрел емкостной сенсорный дисплей Waveshare с демократичной ценой, скромным разрешением и сомнительной поддержкой. В коробке с дисплеем лежала DVD-R DL, и по заявлениям продавца, там лежали образы систем на базе Raspbian. Прочитать их мне не удалось, поиск решений в интернете подсказал, что драйвер, который там лежал, был и так не самым лучшим решением (уже скомпилированное ядро без исходников).

В процессе поиска я наткнулся на проект одного парня из дружественного Китая. Благодаря нему я смог прийти к своему решению.

В этой серии статей я соберу бОльшую часть своего опыта разработки на Ruby on Rails. Эти методики позволяют контролировать сложность и облегчают сопровождение проекта. Большинство из них придумал не я, и, по возможности, буду указывать источник.

Основная проблема проектов на RoR в том, что, как правило, всю логику пытаются уместить в модели, контроллеры и представления. Т.е. код находится только в моделях(ActiveRecord::Base), контроллерах, хэлперах и шаблонах. Такой подход приводит к печальным последствиям: код становится запутанным, долго делаются фичи, появляются регрессии, у разработчиков пропадает мотивация. В качестве примера можно посмотреть на исходники redmine.

Выход из данной ситуации довольно-таки очевидный. Будем делать проекты не на ruby on rails, а с использованием ruby on rails. Как это будет выглядеть: мы никуда не уходим от MVC и Rails, просто пересмотрим Model, View, Controller. Для начала расширим понятие модели. Модель — это не просто класс-наследник ORM. Модель — это вся бизнес логика приложения. Модель включает в себя: модели, сервисы, политики, репозитории, формы и другие элементы, которые я опишу далее. Так же расширим представления. Представления — это шаблоны, презентеры, хелперы, билдеры форм. Контроллеры — это все то, что связано с обработкой запросов: контроллеры, responders.

Всем привет! Меня зовут Андрей Новиков и в последнее время я работаю над проектом по разработке приложения, которое используется в разных частях нашей страны и автоматизирует работу людей. В каждом конкретном часовом поясе нашему приложению необходимо правильно получать, сохранять и отображать время, причём как в прошлом, так и в будущем – например, рассчитать начало рабочей смены и так же правильно его отображать: отсчитать время до конца смены, показать, сколько люди ехали до точки назначения и определить, уложились ли они в норматив, в также многое-многое другое.



За те уже несколько лет, что я пишу на Ruby on Rails, мне не приходилось сталкиваться с подобными проблемами — до этого все мои приложения работали в одном часовом поясе. А тут неожиданно пришлось немало попотеть, отлавливая самые разные ошибки и пытаясь выяснить, как же работать с датой и временем так, чтобы их в дальнейшем избежать.

В результате, сегодня мне есть, чем с вами поделиться. Если вы регулярно встречаетесь с тем, что время сохраняется или отображается некорректно с характерным разбросом в несколько часов (3 часа для Москвы), какие-то ночные записи перекочёвывают на соседние дни, а время упорно отображается не так, как хотят пользователи, и вы не знаете, что со всем этим делать — добро пожаловать под кат.

Capistrano — любимый многими rails-разработчиками инструмент, с помощью которого можно быстро и без заморочек автоматизировать развертывание вашего приложения. Capistrano — стандарт де-факто для системы развертывания RoR, must-know технология для любого уважающего себя рубиста, тот инструмент, которому в своё время завидовали разработчики на python и PHP.
Несмотря на комфорт, от которого не хочется отказываться, чем более сложные задачи мне приходилось решать, тем чаще Capistrano показывал себя к ним не приспособленным.

Я отметил следующие недостатки:

• Известные проблемы со скоростью. Вследствие своей универсальности, Capistrano деплоит медленно, выполняя лишние проверки и вызовы, которые вы не всегда можете контролировать.
• Последовательный деплой. Небыстрое время развертывания нужно умножить на количество целевых серверов (однако, можно настроить распараллеливание комманд явным образом).
• Сильная связанность с рельсами. Конфиги и зависимости Capistrano переплетаются с приложением, становясь его частью. Нельзя создать новое окружение-развертывания (например сервера для раннего выкатывания функционала) без создания нового rails-окружения. В сложных ситуациях Capistrano заставляет уходить от хорошей практики держать только development, test и production окружения.
• Плагины — палка о двух концах. Давая возможность быстро “прикрутить” развертывание той или иной зависимости приложения, плагины лишают вас контроля ситуации, заставляют действовать так, как действует разработчик плагина. О влиянии лишних “телодвижений” плагинов на скорость деплоя я написал выше.
• Сложный деплой гетерогенных приложений. Трендом последних лет в рельсах стало выделение самых тяжелых (бекграундных или сетевых) задач в отдельные сервисы, не обязательно написанные на ruby. В такой ситуации capistrano заставляет вас плодить зоопарк из разных систем развертывания для разных языков и технологий.

Многие ruby-разработчики перешли на Mina или решают свои проблемы с помощью ещё более сложных систем управления конфигурациями вроде Chef и Puppet. Все они имеют свои особенности и недостатки и в разной степени решают описанные выше проблемы. Мне же удалось их решить их с помощью Ansible, не растеряв преимуществ Capistrano, к которым я привык.

Ansible это инструмент для управления конфигурациями и в его задачи входит не только описанное в этой статье выполнение удаленных команд на серверах для развертывания и управления отдельным приложением, но и автоматизация серверного администрирования посредством хранимых серверных конфигураций (ролей на языке Ansible). А значит Ansible (как впрочем и Chef и Puppet) позволяет гораздо больше, чем Capistrano и в конечном счете они все не идут с ним ни в какое сравнение. Однако, задача этой статьи дать rails-разработчикам отправную точку для миграции и разъяснить на этом примере основы Ansible. В конце этой статьи, волшебная команда cap production deploy превратится в ansible-playbook deploy.yml -i inventory/production
Кому интересно как — прошу под кат.