Мы продолжаем публиковать статьи о разработке и производстве сложной современной электроники. В этот раз расскажем об изготовлении прототипов и опытных образцов. Любой проект включает в себя эту стадию, от ее результатов зависит дальнейшая судьба устройства — выход на массовое производство или отправка на доработку.
 
Рабочий образец воплощает в себе результаты работы инженеров, программистов, промдизайнеров и технологов. Его щупают, рассматривают и оценивают, сравнивая ожидаемое с действительным.
 
Зачем вообще нужны эти прототипы? Сколько штук их нужно изготовить в рамках проекта и сколько это стоит? Какие документы нужны для производства опытных образцов? Ответы на эти вопросы вы найдете под катом.
 

Система MajorDoMo объединяет в себе различные компоненты, действие многих из которых сопряжено с чтением либо изменением данных. Для организации эффективного обмена данными между частями системы была создана объектная модель. Данная модель во многом соответствует парадигме Объектно Ориентированного Программирования (ООП) и людям, знакомых с данной парадигмой, не составит труда разобраться в имеющейся модели. Однако, знание принципов ООП совсем не обязательно, т.к. встроенная в систему модель достаточно упрощённая и может применяться без глубокого знания какого-либо языка программирования или же в качестве первого шага обучения этой концепции. В статье описаны основные составляющие этой модели.

Привет, %username%!
Недавно на хабре была опубликована очень спорная статья под названием «Эксперты призывают готовиться к криптоапокалипсису». Честно говоря, я не согласен с выводами авторов о том, что «голактеко опасносте», все скоро взломают и подорожает гречка. Однако я хочу поговорить не об этом.
В комментариях к той статье я высказал мнение, что кое в чем докладчики правы и переходить на эллиптическую криптографию уже давно пора. Ну в самом деле, кто-нибудь видел в интернете ECDSA сертификат? Хотя стандарту уже без малого 13 лет, мы продолжаем по старинке использовать старый добрый RSA. В общем сказал я это, и как это часто бывает, задумался а так ли необходим переход на «эллиптику»? Да и что это за зверь такой эллиптическая криптография? Какие имеет плюсы, минусы, тонкости. Одним словом, давайте разбираться.

Приветствую, уважаемые хабрачитатели! В этой, первой для меня, статье я хотел поделиться своими исследованиями и наработками. Имея в своей квартире кондиционер я ощущал необходимость управлять им когда меня нет дома. Возвращаясь с дачи или просто с работы и, включив кондиционер, приходится ждать некоторое время пока не спадет жара. А хочется приходить в уже легкую прохладу.
«Вот бы можно было удаленно включить кондишн...» — подумал я.

Здравствуйте Хабрасообщество!

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

Решаемые задачи

Основные задачи:

• Взаимодействие с пользователем — Средства для отображение информации и принятии команд от пользователя, например планшетные компьютеры с соответствующим ПО;
• Удалённое управление — Средства исполнения команд пользователя, таких как включить свет, закрыть двери и т.д.
• Мониторинг — Средства сбора информации (датчики температуры/освещенности/вредных газов/открытия дверей/и т.д.);
• Домашняя автоматизация — ЭВМ которая представляет собой сервер для сбора информации, хранения конфигурации системы и исполнения скриптов управления;
• Сопряжение со смежными системами — система должна взаимодействовать с внешними устройствами, такими как телевизор, кондиционер, и.т.д.
• Передача данных — Средства связи всех узлов в единую сеть.

Привет, Хабрасообщество!

У меня вот уже больше 10 лет горит идея сделать такой проект Умного Дома, чтобы любой желающий мог при желании собрать полный прототип из подручных материалов.
Совсем недавно, при общении с некоторыми представителями хабрасообщества, идея была скорректирована под то, что не плохо бы сделать некий массовый блог, где каждый смог бы оставлять свои идеи по поводу реализаций (под это дело я сегодня даже поднял лайвстрит на субдомене своего личного домена, ибо пока не придумал названия для проекта с учётом его новой специфики) + к этому некое хранилище проверенных проектов (на гитхабе. Уже даже есть Gentoo'шный layman'овский репозиторий под это дело) + к этому некую «биржу», где люди далёкие от паяльных дел, но желающие умный дом, могли бы найти желающих чуток подзаработать мастеров паяльного дела в своём городе :).
Дополнительным бонусом являлось бы объединение (по возможности всех) людей, занимающихся этой тематикой «под одной крышей» для обмена идеями и опытом.

Введение

Данная статья является продолжением цикла статей: Использование паттерна синглтон [1], Синглтон и время жизни объекта [2], Обращение зависимостей и порождающие шаблоны проектирования [3], Реализация синглтона в многопоточном приложении [4]. Сейчас я хотел бы поговорить о многопоточности. Эта тема настолько объемна и многогранна, что охватить ее всю не представляется возможным. Здесь я заострю внимание на некоторых практичных вещах, которые позволят вообще не думать о многопоточности, ну или думать о ней в крайне минимальном объеме. Если говорить точнее, то думать о ней только на этапе проектирования, но не реализации. Т.е. будут рассмотрены вопросы о том, как сделать так, чтобы автоматически вызывались правильные конструкции без головной боли. Такой подход, в свою очередь, позволяет значительно уменьшить проблемы, вызванные состояниями гонок (race condition, см. Состояние гонки [5]) и взаимными блокировками (deadlock, см. Взаимная блокировка [6]). Этот факт уже сам по себе представляет немалую ценность. Также будет рассмотрен подход, который позволяет иметь доступ к объекту из нескольких потоков одновременно без использования каких-либо блокировок и атомарных операций!

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

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

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

Вторая причина гораздо более прозаична. Невнимание к мелочам. Особенно в начале проекта. И чем моложе команда, тем эффект катастрофичнее. Конечно, гораздо интереснее обсуждать перспективы использования мультиметодов [1], чем следить за тем, чтобы операторы отделялись пробелами. Да и к конечной функциональности подобные мелочи особого отношения не имеют. Не лучше ли сначала сконцентрироваться на первоочередных требованиях, ведь время проекта и бюджет ограничены…

Большинство web-приложений и web-фреймворков используют архитектуру, не позволяющую разделить ui и backend разработку. Тем самым нет возможности разделить команду на узкоспециализированных frontend и backend разработчиков. Вне зависимости от предпочтений разработчика ему приходится иметь понимание как о слое представления, так и о слое логики. Если ui-разработчик знает только о том, как запустить сервер, и о модели данных — это огромная удача. В плохих случаях ui-разработчику необходимо провести полную сборку проекта чтобы увидеть изменения строчки в javascript файле, или знать о языке jsp файлов чтобы поменять стиль элемента. Формирование и передача на сервер обработанных html файлов так-же пагубно влияет на производительность сервера и сети.

Многие сервисы и приложения (особенно веб-сервисы) принимают древовидные данные. Например, такую форму имеют данные, поступающие через JSON-PRC, JSON-REST, PHP-GET/POST. Естественно, появляется задача валидировать их структуру. Существует много вариантов решения этой задачи, начиная от нагромождения if-ов в контроллерах и заканчивая классами, реализующими валидацию по разнообразным конфигурациям. Чаще всего для решения этой задачи требуется рекурсивный валидатор, работающий со схемами данных, описанными по определённому стандарту. Одним из таких стандартов является JSON-Schema, рассмотрим его поближе.

STM32F4Discovery – подключаем камеру по интерфейсу DCMI

Когда-то, подключая камеру от мобильного телефона к микроконтроллеру STM32F407VGT6 (который имеет место быть на плате STM32F4Discovery), я даже не думал о том, что данный контроллер имеет специальный аппаратный интерфейс для данного дела. Может быть, невнимательно читал даташит, но я всегда считал, что интерфейс DCMI имеется только у чипов в корпусах UFBGA176 и LQFP от 144 ног. Однако, не так давно, открыл для себя озвученную деталь: 100-ногий STM32F407 также имеет DCMI на борту.
Являясь большим любителем изучения и совместного запуска различного мобильного железа (в частности, LCD и камер) с МК, мимо такого открытия я просто так пройти не смог, и решил восполнить данный пробел в изучении периферии STM32. Собственно, данный материал и посвящен описанию осуществления возникшей затеи.

Зарегистрирован на хабре с 9 июля 2008. Ни разу ничего не писал, только читал, Карма ниже нуля. Решился.
Сразу обращение к уважаемому «хабрасообщесту» статья это попытка разобраться в тех вопрос которые для меня ещё как бы не до конца поняты, поэтому жду конструктивную критику и понятные отзывы, а не «ты дурак и всё».Теперь и к теме приступим.

Справочный API 2ГИС разрабатывается уже 4 года. Появилось около 40 методов, которые возвращают достаточно крупные и иерархически сложные структуры в формате JSON и XML. Совсем недавно я решил поделиться накопленным опытом и выступить на конференции DevConf.
Одна из тем доклада вызвала наибольший интерес у участников — это использование JSON-Schema при тестировании формата выдачи API. В этой статье я расскажу, какие задачи решает этот подход, какие имеет ограничения, что вы получаете из коробки, а что идёт бонусом. Поехали!

В повседневной практике разработчика встраиваемых систем приходится сталкиваться с необходимостью запуска двух и более разноплановых ОС на n-ядерных системах на кристалле. Это, как правило, Linux и специализированная RTOS. На плечи Linux ложится работа с тяжеловесными стеками протоколов, а RTOS же занимается задачами реального времени.
 
Одна из основных задач, которая встает при такой организации системы — обеспечение механизма взаимодействия, то есть межъядерный обмен данными. Если вам интересно узнать один из вариантов решения на базе открытой библиотеки OpenMCAPI, пролистать пару десятков строк программного кода и увидеть реальные цифры пропускной способности при использовании этой библиотеки, добро пожаловать под кат.

C тех пор, как я опубликовал первую обзорную статью о биоинформатике, прошел уже почти год. Хотелось бы писать чаще, но как раз биоинформатика отвлекаться и не дает. В предыдущей статье была упомянута задача сборки генома, а также Лаборатория алгоритмической биологии (СПбАУ РАН), в которой ей занимаются. Как уже было сказано, над этой задачей работают во многих университетах мира давно и достаточно успешно. Однако для сборки генома биологи получают огромное количество различных типов данных, каждый из которых имеет свои особенности. Около пяти лет назад появилась технология MDA, открывшая большие возможности в области изучения бактерий. В результате появился тип данных, для которого потребовался новый геномный сборщик. Через несколько лет он был разработан, и не в Стэнфорде или Массачусетсе, а в Санкт-Петербурге, в молодом Академическом университете. Но обо всем по порядку.

«Система должна быть спроектирована так,
чтобы оставаться как можно проще
после серии внесенных в нее изменений»
Бьярне Строуструп – программист, автор языка C++

Преамбула

В данной статье мне бы хотелось бы рассказать о довольно популярной, но так редко освещаемой на Хабре библиотеке Portable Components (сокр. POCO). Она будет полезна как разработчикам бизнес-логики программного продукта, так и в решении большинства прикладных задач. При всем изобилии кроссплатформенных библиотек для C++ всё больше людей сталкиваются с POCO лицом к лицу и не знают с чего начать. В данной статье я постараюсь описать технологии, заложенные в библиотеке и дать простейшие примеры решения некоторых задач. Также хотелось бы отметить, что за плечами библиотеки множество успешных как Open Source, так и коммерческих проектов.

Недавно появилась заметка о простой и эффективной «ручной» сборке мусора в С++. Вполне допускаю, что локальная сборка мусора внутри какого-то сложного класса (где идёт активная низкоуровневая работа с указателями) может быть оправдана. Но в масштабах большой программы, существует более надёжный и простой метод избавления от утечек памяти. Не претендуя на «метод на все случаи жизни», очень надеюсь, что он сделает проще жизнь хотя бы некоторым из читателей.

Суть метода предельно проста: если каждый объект является переменной какой-либо области видимости или простым («стековым») членом другого объекта, то даже при аварийном закрытии программы от необработанного исключения, всегда будет происходить корректная очистка. Задача заключается в том, чтобы свести всё многообразие динамических сценариев к этой схеме.

Я бы хотел поделиться одним способом создания личного облака на базе трехтеррабайтного WD MyBook Live. Нет, я не буду даже упоминать про wd2go и их «полуоблака», которые по сути являются только доступами к самому NAS через сервисы WD при помощи довольно корявых Java-апплетов. В этой статье речь пойдет о «честном» облаке, работающем на MBL при помощи ownCloud.
Это решение подойдет тем, кто мечтает о личном аналоге Dropbox, файлы в котором хранятся не «где-то там», а на конкретном физическом носителе, и ограничены только его объемом, без необходимости платить ежемесячно за этот объем (пренебрегая абонентской платой за интернет и стоимостью электроэнергии).
Большинство решений подобной задачи требуют достаточно много покопаться в интернете и опираются на хорошее знание Linux-систем. В данном посте я попытаюсь дать наиболее полный и адекватный HOW-TO на русском, чего сам в интернете не нашел. Так что многое пришлось делать методом проб и ошибок на свой страх и риск. Реализация данного решения не требует каких-либо фундаментальных знаний Linux, и я постараюсь расписать все наиболее доступно, по шагам.

Если интересно что из этого вышло — добро пожаловать под кат.

Всем привет! В одной из наших предыдущих статей мы рассказали о реализации функции асинхронного пинга в рамках задачи по созданию «пингера» для его дальнейшего использования при пентестах организаций с большим количеством рабочих станций. Сегодня мы поговорим о покрытии нашего пингера (логика и сетевая часть) модульными тестами.

Понятно, что необходимость написать код, который пройдет тестирование, — дисциплинирует и помогает грамотнее планировать архитектуру. Тем не менее, первая мысль о покрытии юнит-тестами асинхронного кода на Boost.Asio была примерно такая: «Что?! Это абсолютно невозможно! Как можно написать тест, основанный на сетевой доступности узла?»

Продолжая цикл статей об Hyperboria, в этой статье будут рассмотрены следующие аспекты:
1) Количество IP адресов в Hyperboria, как они генерируются.
2) Коллизии и как с ними бороться.
3) Почему используется служебный (приватный) диапазон IPv6 адресов.
4) Роутеры и Hyperboria.
5) Маршруты и DHT.
6) Защищенность сети.