Рано или поздно, занимаясь DIY-разработкой, проектированием IoT устройств и тому подобным творчеством (или работой), вы приходите к необходимости защищать свои устройства и их коммуникации от взлома, кражи и подделки хранимых и передаваемых данных. Особенно это актуально в популярной области «интернета вещей», где вся система является распределённой и между её частями, хабами, датчиками и прочими элементами, происходит постоянный обмен информацией.

Первое, что приходит в голову — это реализация криптографической защиты программными средствами, например, защита передаваемых данных при помощи связки SHA-256/AES. Для большинства современных микроконтроллеров существуют соответствующие библиотеки, которые успешно работают даже на таких слабых MCU как ATmega328.

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

Что же делать?

О чём речь

Появление на Хабре поста о фильтре Маджвика было по-своему символическим событием. Видимо, всеобщее увлечение дронами возродило интерес к задаче оценивания ориентации тела по инерциальным измерениям. При этом традиционные методы, основанные на фильтре Калмана, перестали удовлетворять публику — то ли из-за высоких требований к вычислительным ресурсам, неприемлемых для дронов, то ли из-за сложной и неинтуитивной настройки параметров.

Пост сопровождался весьма компактной и эффективной реализацией фильтра на C. Однако судя по комментариям, физический смысл этого кода, а равно и всей статьи, для кого-то остался туманным. Что ж, признаем честно: фильтр Маджвика — самый замысловатый из группы фильтров, основанных в общем-то на очень простых и элегантных принципах. Эти принципы я и рассмотрю в своём посте. Кода здесь не будет. Мой пост — не рассказ о какой-то конкретной реализации алгоритма оценивания ориентации, а скорее приглашение к изобретению собственных вариаций на заданную тему, которых может быть очень много.

Одна из интересных технологий “интернета вещей” — сети LoRa/LoRaWAN, однако в рунете они практически не описаны. Пора восполнить этот пробел, и тем более интересно попробовать “вживую”, как это работает.

Что такое LoRa?

Это технология связи на большие (Long Range) расстояния, запатентованная компанией Semtech, и реализованная в их чипах SX1272 and SX1276. LoRa это протокол низкого уровня, поверх которого могут реализовываться более высокоуровневые протоколы, например LoRaWAN.

Особенность стандарта LoRa — это передача небольших пакетов данных с невысоким энергопотреблением. По заверениям производителя, дальность на открытом воздухе может достигать 10км, а время работы от батареи может составлять несколько лет. Рабочие частоты зависят от страны, и составляют 433 или 868МГц (EU-версия) или 915МГц (USA-версия).

Как это работает? Подробности под катом.

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

Что же, в последнее время, в своей работе я во всех проектах задействую lodash (кому-то может больше нравиться underscore). Для меня это, фактически, — стандарт. В очередной раз пробегая глазами API, я решил составить для себя шпаргалку в виде: «название функции» — «краткое описание». Так удобно освежать API в памяти. Может кому пригодится.

Друзья, как вы уже знаете, мы на всех парах готовим новый гик-проект — «Сервер в облаках 2.0», или «Космический ЦОД». В двух словах: 12 апреля мы запустим самопальный сервачок на стратостате на высоту около 30 км, будем передавать на него данные через систему космической связи, а с сервера транслировать данные на Землю по радиосвязи.

И сегодня хотим рассказать о трёх системах космической связи, которые протестируем в своём проекте — Iridium, GlobalStar и «Гонец». Для этого мы смонтируем приёмную аппаратуру рядом с нашим заоблачным сервером.

(Нашёл в твиттере тред с очень крутым объяснением работы симметричных шифров. Его написал Colm MacCárthaigh один из основных контрибьюторов Apache. Я спросил разрешение Колма на перевод, он любезно согласился).

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

Итак, симметричное шифрование — это именно то, что мы используем в большинстве случаев, когда хотим зашифровать кучу данных. Ваш браузер отправляет и получает данные, используя симметричное шифрование. Если вы шифруете файлы или диск, в этом случае тоже работает симметричное шифрование. iMessage, Signal, WhatsApp — все они используют симметричное шифрование для безопасности вашей переписки.

Если вы думаете, что при шифровании данные перемешиваются так, что их никто не может прочитать без ключа, так оно и происходит на самом деле.

Вот простой пример. Допустим, у меня есть строка "Ovaltine" и я хочу её зашифровать. Я мог бы воспользоваться rot13 — очень простым олдскульным шифром Цезаря, который делает хоровод из букв, где a и z держатся за ручки, и заменяет каждую букву другой буквой алфавита, которая находится от заменяемой буквы на расстоянии 13 символов. Таким образом "O" превращается в "B", а "v" становится "i", в итоге "Ovaltine" превращается в "Binygvar". Конечно, это не очень безопасно. Это наивный пример, который очень легко взломать, так как атакующий может выяснить, какая буква встречается чаще всего (обычно в оригинальном тексте это "e") и найти оставшиеся буквы подобным образом.

Здравствуйте, хабрапользователи! В этой статье речь пойдет о предметно-ориентированном проектировании программного обеспечения с использованием, в первую очередь, стратегических шаблонов. Вторую часть – про тактическое проектирование – читайте здесь.

Данный подход использовал Вон Вернон в своей книге «Реализация методов предметно-ориентированного проектирования». Цель написания этой книги: дать возможность разработчикам совершить полет на самолете DDD (в детстве автор зачастую путешествовал со своей семьей на небольших самолетах). Вид с высоты дает более широкое представление о проблемах моделирования, не давая застрять в различных технических деталях. Наблюдая ландшафт DDD таким способом, можно осознать преимущества как стратегического, так и технического проектирования. Подробнее – под катом!

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

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

Предисловие

(из статьи КОМПЬЮТЕРНАЯ СТЕГАНОГРАФИЯ ВЧЕРА, СЕГОДНЯ, ЗАВТРА. Технологии информационной безопасности 21 века. /Барсуков В. С., к.т.н., Романцов А.П./1998/)
Задача надежной защиты информации от несанкционированного доступа является одной из древнейших и не решенных до настоящего времени проблем. Способы и методы скрытия секретных сообщений известны с давних времен, причем, данная сфера человеческой деятельности получила название стеганография. Это слово происходит от греческих слов steganos (секрет, тайна) и graphy (запись) и, таким образом, означает буквально “тайнопись”, хотя методы стеганографии появились, вероятно, раньше, чем появилась сама письменность (первоначально использовались условные знаки и обозначения).
В дальнейшем для защиты информации стали использоваться более эффективные на время создания методы кодирования и криптографии.
Как известно, цель криптографии состоит в блокировании несанкционированного доступа к информации путем шифрования содержания секретных сообщений. Стеганография имеет другую задачу, и ее цель — скрыть сам факт существования секретного сообщения. При этом, оба способа могут быть объединены и использованы для повышения эффективности защиты информации (например, для передачи криптографических ключей).
Как и любые инструменты, стеганографические методы требуют к себе внимания и осторожного обращения, так как могут быть использованы как для целей защиты, так и для целей нападения.

Алгоритм

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

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



Сегодня, в переводе 16 части серии материалов, посвящённых всему, что связано с JavaScript, мы поговорим о механизмах хранения данных на стороне клиента, которые могут использоваться в веб-разработке, и о выборе системы хранения данных для конкретного проекта.

Перед вами перевод пятой части руководства по разработке веб-решений на базе Node.js, Vue.js и MongoDB. В первой, второй, третьей и четвёртой частях мы рассказывали о поэтапном создании клиентской и серверной частей приложения Budget Manager. Те, кому не терпится увидеть в действии то, что в итоге получилось у автора этого материала, могут заглянуть сюда. Кроме того, вот GitHub-репозиторий проекта. Если вы — из тех, кто ценит строгую типизацию, то здесь и здесь находятся результаты переноса Budget Manager на TypeScript.



Сегодня работа над этим учебным проектом завершится. А именно, в данном материале пойдёт речь о разработке страниц по добавлению в систему записей о новых клиентах и финансовых документах, а также о создании механизмов для редактирования этих данных. Здесь же мы рассмотрим некоторые улучшения API и доведём Budget Manager до рабочего состояния.

Перед вами четвёртая часть серии материалов, которые посвящены разработке веб-приложения Budget Manager с использованием Node.js, Vue.js и MongoDB. В первой, второй и третьей частях речь шла о создании основных серверных и клиентских компонентов приложения. Сегодня мы продолжим развитие проекта, а именно — займёмся списками документов и клиентов. Кроме того, нельзя не заметить, что к настоящему моменту сделано уже немало, поэтому вполне можно критически взглянуть на то, что получилось, и поработать над повторным использованием кода.

Сегодня публикуем третью часть из серии материалов, посвящённой разработке приложения Budget Manager с использованием Node.js, Vue.js и MongoDB. В первой и второй частях мы создавали сервер, настраивали механизмы аутентификации и занимались обустройством фронтенда. В этом материале продолжим работать над клиентской и серверной частями системы. То, что уже создано, пока почти не касается логики самого приложения, которое предназначено для работы с финансовыми документами. Поэтому, кроме прочего, мы займёмся и этим аспектом проекта.

A forwarding entity always forwards packets in per-flow order to
zero, one or more of the forwarding entity’s own transmit interfaces
and never forwards a packet to the packet’s own receive interface.
Brian Petersen. Hardware Designed Network

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

А через 10 минут он закажет такси через приложение на телефоне, и ему не придётся даже брать с собой в дорогу наличку.

В аэропорту он купит кофе, расплатившись часами, сделает видеозвонок дочери в Берлин, а потом запустит кинцо онлайн, чтобы скоротать час до посадки.

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

Это ли не электрическая магия?

В своём вояже к QoS, теме обещанной многократно, мы сделаем ещё один съезд. На этот раз обратимся к жизни пакета в оборудовании связи. Вскроем этот синий ящик и распотрошим его.


Кликабельно и увеличабельно.

Сегодня:

1. Коротко о судьбе и пути пакета
2. Плоскости (они же плейны): Forwarding/Data, Control, Management
3. Кто как и зачем обрабатывает трафик
4. Типы чипов: от CPU до ASIC'ов
5. Аппаратная архитектура сетевого устройства
6. Путешествие длиною в жизнь

Если вы наслышаны о так называемых «трансдьюсерах», но до сих пор не применяете их в JavaScript-разработке, сегодня у вас есть шанс найти ответы на вопросы: «Что такое трансдьюсеры?» и «Как ими пользоваться?». Это позволит вам понять, нужны ли они в ваших проектах, и, если нужны — поможет приступить к их использованию.



Речь пойдёт о том, как писать код, который предназначен для построения хорошо подходящих для компоновки конвейеров преобразований данных, не потребляющий слишком много памяти. Для того, чтобы как следует разобраться в концепции трансдьюсеров, начнём мы с более простых механизмов, редьюсеров, или функций для свёртки данных.

Тенденция распространения программно-конфигурируемых (software defined) решений давно докатилась и до корпоративных центров обработки данных. «Правильный» ЦОД сегодня – это ЦОД программно-конфигурируемый или, как еще говорят, программно-определяемый (SDDC). По информации аналитических агентств, более 75% компаний уже работают с программно-определяемыми ЦОД, при этом уровень виртуализации в них продолжает расти.

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

Проект freeCodeCamp провёл опрос 2017 New Coder Survey, в котором приняли участие более 20000 человек со всего мира. Эти данные, содержащие ответы респондентов на примерно 50 вопросов, выложены в открытый доступ на GitHub (Open Data Common License).

Собранные результаты позволяют исследователям, которые занимаются вопросами компьютерного образования среди взрослых, узнать немало интересного. Полагаем, эти данные заинтересуют многих, нам остаётся лишь догадываться о том, какие открытия будут сделаны на основе их анализа.

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

Мне доводилось видеть множество Linux-серверов, которые, без единой перезагрузки, работали годами, в режиме 24x7. Но ни один компьютер не застрахован от неожиданностей, к которым могут вести «железные», программные и сетевые сбои. Даже самый надёжный сервер может однажды отказать. Что делать? Сегодня вы узнаете о том, что стоит предпринять в первую очередь для того, чтобы выяснить причину проблемы и вернуть машину в строй.

И, кстати, в самом начале, сразу после сбоя, стоит ответить на весьма важный вопрос: «А сервер ли виноват в том, что случилось?». Вполне возможно, что источник проблемы совсем не в нём. Но, не будем забегать вперёд.

Многие считают, что микросервисы — это очень сложно. На самом же деле, при правильном подходе, это совсем не так.

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

Перед вами — вторая часть серии материалов, которая посвящена созданию веб-приложения Budget Manager с использованием Node.js, Vue.js и MongoDB. В первой части мы занимались сервером, а именно — подготовили основные методы RESTful API и наладили JWT-аутентификацию. Сегодня приступим к работе над клиентской частью приложения, создадим каркас фронтенда, средства для регистрации в системе и входа в неё, поговорим о маршрутах и об их защите.