Юрий Ярош

Я очень давно не работал с STM32, но обычно такие вещи решает DMA и трансляция irq в soft-irq. Идея в том что бы получить прерывание от USB - оставить его "на потом" в виде обработчика softirq, а данные писать с i2c прямо в память через DMA. Когда сбор данных завершится - выполнить обработку всех отложенных прерываний в порядке следования.

Есть такая весёлая модель как MVCC.
Все весельё начинается когда транзакции начинают писаться на нескольких узлах одновременно - точно сказать что устарело и какие конфликты возникли бывает сложно. По этому безопасно что-то удалить, без синхронизации состояний с последующей проверкой консистентности на всех узлах невозможно... вот всякие WebLogic'ы не знают что у вас один узел, и даже с одним узлом у них проблемы.

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

"Просто удалить" нельзя из-за специфики проверок консистентности лога транзакций - весь лог должен быть применён от начала до конца. Часто используют специфические коды Рида-Соломона для дополнительной отказоустойчивости при порче информации на диске, они вносят свои ограничения.

Рассмотрите модель работы Riak, там для обозначения транзакций используются метки Лампорта... вот просто "взять и удалить" без последствий в сложной транзакционной системе не получится.

Нужно смотреть курсы Computer Vision и книгу

Непосредственно по OpenCV все материалы и ресурсы успели устареть, так как сейчас много чего ушло в сторону расчетов на OpenCL. посредством нового стандарта OpenVX.

В самом OpenCV реализовано два метода классификации объектов:
Latent SVM метод основанный на анализе градиентов
Эмперический метод на основе анализа границ

SVM более точный и более ресурсоёмкий.

Разберётесь с матчастью - будет проще понять как работать со стандартными методами.

А причем здесь микросхемы ?
Люди обычно понимают это слово как "чип" а не как разработку электрической схемы...
Форум - есть радиокот. Задача звучит приблизительно следующим образом "нужно разработать схему с двумя триггерами что бы при срабатывании одного - блокировался другой. И оба сбрасывались одной кнопкой сброса".

Нужно RESTfull API реализовать.
Вот вопрос заключается как и на чем лучше для конкретного решения.
Какое РНР, и на чем сайт написан ?

В случае CMS/CMF - нужно искать или писать плагины для них.

В случае с РНР5.2 и Yii-образными сайтами все довольно посредственно, хотя есть тутор.

В случае с РНР5.3 люди часто используют swagger c silex'ом.

Ну и на symfony2 можно поискать бандлы, хотя обычно люди делают вот так

Я бы смотрел в сторону Angular, Play2, swagger, Jooq, Apache DirectMemory и не заморачивался с энтерпрайсом. Как показывает практика J2EE стэк не очень подходят для фриланса. Конечно есть исключения - можно глянуть Grails, Vaadin и ZK для RAD'а.
У Grails ужасно низкий порог вхождения, я на него подсаживал рельсозависимых и джангистоманов; там уровень поддержки на несколько порядков лучше чем в большинстве решений из миров php/ruby/python.

J2EE сейчас немного парализован, и с его использованием в продакшене связано не мало рисков. В первую очередь участились случаи взлома серьёзных учреждений которые используют JBoss и WebLogic. Сейчас как-то стало совсем непопулярно использовать сервлеты ...

JSF / ADF сейчас отмирает.
Spring очень простая и нужная штука если разобраться, правда есть свои проблемы и иногда лучше обойтись без него.

По шаблонам проектирования, важно понимать: mvc, mvp (document-view), mvvm, cqrs-es, disruptor, proactor / reactor. Все остальное, "банальное" типа Factory, Builder, Facade можно подчерпнуть из книжек... в вэбе такое почти не используется, но для понимания остальных шаблонов нужно разобраться.

В большинстве случаев мне приходится реализовывать CQRS-ES в Play2 через Angular + sse. Есть свои сложности с http кэшированием, и кэшированием модели... часто использую prerender.io для клиентов без JS'а и поисковых роботов. Вэбсокеты (Socket.io) работают медленнее (задержки выше, инициализация длительнее) чем sse, иногда приходится откатываться на флеш и long-polling, но это все по ходу дела приходится самому дописывать руками. Есть много классных решений типа restangular, правда большинство из них ещё довольно сыроваты - доверяю тому что сам пишу.

Собственно если есть свой "корпоративный" дизайн, то лучше смотреть в сторону AIR с Flex'ом. Флешеров сейчас довольно много, и AIR довольно шустро бегает на iOS и Android.
Под AIR можно писать нативные расширения для конкретных платформ, если не хватает встроенного функционала. Мне приходилось разрабатывать приложения на feathers, в принципе есть проблемы с производительностью и рендерингом, но вполне съедобно.

Собственно PaaS / SaaS проекты требуют реактивных подходов.
Так что вопрос о целевой платформе/фреймворке сформулирован не совсем корректно.

В первую очередь нужно понимать что прийдется работать с CQRS-ES, а не с MVC / MVP.
И там нужны различные многопоточности, да ассинхронности...
Возможность работы с SSE / Websocket'ами.
И никаких "один клиент - один поток/процесс"

В интерпретируемых языках - php / python / ruby / perl, кроме node.js, нет этих плюшек.
Часто используют всякие прокладки и костыли типа beanstalk и gearman
Называют это все "высоконагрузом"... вот наивные

node.js не вариант
Максимум на нем можно реализовать prerender.
SaaSы на node будут сложны в поддержке и разработке.
Ну разве что вы уверенны что сможете найти джедаев в СНГ, которые точно будут с этим работать 2-3 года... что собственно фантастика.

Могу посоветовать только swagger Play2 jooq + apache DirectMemory.
Возможно также использовать Grails + atmosphere, но там проблемы с производительностью.

В "богатых фронтендах" проблем хватает, и выбор не велик.
Сейчас есть только angular. Все остальное либо с утечками памяти, либо довольно сырое и дырявое. У ангуляра тоже не все сладко, вот к примеру нет поддержки httр кэширования в REST ресурсах. Хотя есть restangular, но ещё довольно сырой. В общем есть нюансы которые могут сильно тормозить разработку проектов при специфических требованиях.

Если не хочется плясать с html / js то лучше вооще не смотреть в сторону JS фреймворков.

Для j2ee есть vaadin zk
Отлично интегрируются с Grails.

Не могу сказать что работают очень гладко, но в целом генерируемый html / css / js довольно вменяемый, и кастомизация проходит с пол-пинка.

ИМХО ExtJS шлак, хотя и ExtGWT туда же ...
Порог вхождения не так высок как пишут - документация хреновая и дилетантов много.
По большему счету большое bloatware.

Для яблофилов можно глянуть cappuccino
Правда там сейчас тотальная перетрубация и раздел власти, будущее проекта довольно туманно.