Чего «репу» чешешь?
На золотую рыбку другая сеть нужна!

Собственно, я собирался продолжить серию топиков, посвященных работе RTLS – системы позиционирования в реальном времени. А именно, рассказать о беспроводной инфраструктуре системы, основанной на сетях ZigBee. Но вдруг с удивлением обнаружил, что на Хабрахабре нет публикаций, посвященных стандарту IEEE 802.15.4 и спецификации ZigBee. Есть лишь немногочисленные упоминания, связанные с тем или иным приложением. Попытаюсь по мерее сил заполнить этот пробел.

В последнее время все большее распространение и значение приобретают беспроводные сенсорные сети. Сети, которые по своему назначению, параметрам, спецификациям существенно отличаются от сетей связи – WiFi, GSM, LTE и т.п. Среди прочих, используемых в сенсорных сетях, выделяется спецификация ZigBee – наиболее продвинутая надстройка к стандарту IEEE 802.15.4
В этом году исполнилось 10 лет со времени основания ZigBee альянса, а в октябре исполняется 5 лет с момента утверждения действующей в настоящее время спецификации ZigBee Pro Feature Set 2006. Так что публикацию можно считать юбилейной.

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

2 года назад передо мной встала задача реализовать удаленное управление обогревательными приборами в своем загородном доме. В данной статье я хочу поделиться моим вариантом автоматизации и удаленного управления, к которому я в итоге пришел. Постараюсь охватить весь процесс и подробности создания этого хобби-проекта и поделиться всеми сложностями, с которыми пришлось столкнуться. В процессе реализации, как видно из названия статьи, я использовал Noolite (о нем расскажу в статье), Telegram и совсем немного Python.

Здравствуйте уважаемые читатели Geektimes! На этот раз я хочу представить вашему вниманию цикл статей об интеграции беспроводного оборудования nooLite в системы домашней автоматизации. Этот цикл будет похож на уже вышедшую серию статей (раз, два, три) об интеграции модулей Laurent в системы Умного дома, только рассказываться в нём будет о системе nooLite и после прочтения этого цикла у вас не останется вопросов по управлению приборами nooLite из вашего Умного дома.

Итак, переходим ко второй части нашего повествования об интеграции беспроводного управления nooLite в системы домашней автоматизации. И в этой части мы поговорим о управляющем модуле nooLite MT1132 и его интеграции в популярную систему Arduino Mega Server. Это расширяет (и без того очень развитые) возможности AMS беспроводным управлением светом и электроприборами в вашем Умном доме.

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

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

Если разделять языки программирования по популярности, то они делятся на три эшелона. Первый эшелон включает мейнстрим-языки, такие как Java, JavaScript, Python, Ruby, PHP, C#, C++ и Objective-C. Несмотря на то, что некоторые из ведущих языков возможно увядают, вам лучше знать один или несколько из них, если вы хотите иметь возможность легко найти работу.

Языки второго эшелона пытаются пробиться в мейнстрим, но ещё не добились этого. Они доказали свою состоятельность путем создания сильных сообществ, но они до сих пор не используются большинством консервативных IT-компаний. Scala, Go, Swift, Clojure и Haskell — языки, которые я бы отнёс ко второму эшелону. Некоторые компании используют эти языки для отдельных сервисов, но широкое применение встречается редко (за исключением Swift, который начинает обгонять Objective-C в качестве основного языка для iOS). Go и Swift имеют хорошие шансы на переход из второго эшелона в первый в течение ближайших двух-трёх лет.

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

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

Этот документ поможет вам изучить контейнер для языка программирования Rust — futures, который обеспечивает реализацию futures и потоков с нулевой стоимостью. Futures доступны во многих других языках программирования, таких как C++, Java, и Scala, и контейнер futures черпает вдохновение из библиотек этих языков. Однако он отличается эргономичностью, а также придерживается философии абстракций с нулевой стоимостью, присущей Rust, а именно: для создания и композиции futures не требуется выделений памяти, а для Task, управляющего ими, нужна только одна аллокация. Futures должны стать основой асинхронного компонуемого высокопроизводительного ввода/вывода в Rust, и ранние замеры производительности показывают, что простой HTTP сервер, построенный на futures, действительно быстр.

Когда в нашей компании LTD BeGet встала задача прозрачной фильтрации атак на 4 уровне модели OSI, мы написали свое решение Syncookied. Данным решением мы бы хотели поделиться с Internet-сообществом, так как на текущий момент аналогов ему мы не нашли (или мы о них не знаем). Есть платные решения на подобии Arbor, F5, SRX, но стоят они совершенно других денег и в них используются другие технологии защиты.

Почему для разработки мы выбрали язык Rust и фреймворк NetMap, с какими сложностями мы столкнулись в процессе — будет рассказано в этой статье.

» GitHub
» GitHub модуль ядра
» Страница проекта

Данная статья в некотором роды выжимка того, что Вы могли бы узнать просмотрев разные видео ролики господина Шипилева, Елизарова, Смирнова. Собственно мы даже собрали для Вас плейлист если Вы захотите пойти «the hard way». В статье я лишь попробую Вам передать некоторые основные мысли/идеи, которые при желании Вы сможете намного более глубоко изучить в первоисточниках.

Итак, давайте теперь перейдем к собственно сабжу. Еще лет пять назад можно было не сильно «парясь» выдавать на-гора однопоточные программы, которые с трудом запускались на топовом железе и знать, что через год-два этот кусочек “программки” (простите за аллегорию) начнет работать нормально. Сегодня подобный «бесплатный обед» закончился.


На картинке четко видно, что количество транзисторов все еще растет, но с точки зрения частот мы практически достигли потолка. «Кривизну» рук разработчиков уже трудно компенсировать тем, что через год железо станет работать в два раза быстрее. Хотя не все так печально, процессоры пока еще растут, только с точки зрения количество ядер. Как следствие, для того чтобы «программка», написанная криворуким орком, смогла хоть как-то нормально работать на новом железе, нужно чтобы она нормально работала в многопроцессорной среде. А производительность была напрямую связана с количеством ядер на железе. Вот собственно от том, а что же такое «нормально работала многопроцессорной среде» мы и поговорим далее.

Два года назад в OpenJDK был создан новый проект под кодовым названием «Panama». Основным направлением исследований анонсировалось создание нового интерфейса для работы с платформозависимыми библиотеками и данными вне Java heap’а (off-heap). Но цели проекта шире: исследование механизмов взаимодействия JVM и «внешнего» (не-Java) API.

Владимир Иванов iwanowww — ведущий инженер Oracle, работает в группе разработки виртуальной Java-машины HotSpot. Специализируется на JIT-компиляции и поддержке альтернативных языков на платформе Java. Владимир пришел в Sun Microsystems (приобретена Oracle в 2010) в 2005 году и с того момента поучаствовал в большом количестве проектов, связанных с Java (HotSpot JVM, RTSJ, JavaFX).

JNI 2.0?

— Большая часть проекта Panama — это работа с native библиотеками из Java кода. Как это можно делать сейчас?

— Работать с native кодом в Java можно было всегда. Native методы были еще в первой версии Java, а стандартный интерфейс JNI появился уже в версии 1.1. Но время идет, платформа развивается, требования меняются и, смотря на JNI сейчас, есть понимание, что можно организовать работу с native библиотеками удобнее и эффективнее.

В течение последних лет можно было наблюдать использование различных подходов к построению навигации в Android-приложениях. Кто-то использует только активности (Activity), кто-то смешивает их с фрагментами (Fragment) и/или с модифицированными видами (Custom View).

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

В этой статье мы рассмотрим несколько характерных подходов к реализации навигации в Android, а затем поговорим о подходе с использованием фрагментов, сравнив его с другими подходами. Демонстрационное приложение, на примере которого иллюстрирована статья, можно скачать с GitHub.

Привет, Geektimes!

Я реализую свой умный дом и хочу поделиться несколькими выстраданными решениями.

В качестве центрального контроллера в моей версии умного дома я использую Raspberry Pi с установленными Domoticz и MQTT брокером Mosqito. Центральный контроллер управляет разнообразными нагрузками, зачастую расположенными достаточно далеко от основного здания, например, в гараже или в теплице. В таких удаленных узлах я использую недорогие UDP реле KMTronic для коммутации нагрузок и Ардуино с Ethernet Shield для сбора данных и обратной связи.

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

Всем бодрого/доброго (нужное подчеркнуть) времени суток и хорошего настроения! Хочу рассказать и показать процесс, как я придумывал (проектировал) и изготавливал базовое шасси для четырёхколёсного робота.

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



Цель этого поста – показать процесс разработки и изготовления подобной платформы. Обычно в статьях по робототематике показывают уже готовые устройства, демонстрируя, что сделано и как оно в результате работает. Это интересно, конечно же. Но с бóльшим удовольствием я читаю статьи, в которых поэтапно показывается, как именно сделано, почему и описание каких-то отдельных моментов или мыслей. Я попробую подробно описать как собиралась движущаяся платформа в домашних условиях. Эта статья – профильное чтение для отдыха. Саму статью я подготавливал, наверное, больше времени раза в три, чем рукоделием занимался. Не претендую на полноту описания, высокотехнологичность, наукоёмкость, инновационность и безошибочность… Но надеюсь, что для кого-то она поможет сделать какие-то первые шаги и покажет, что современная модульная электроника это совсем не сложно, хотя и не совсем просто, как кажется. «Дяди снова играют в машинки вместо того, чтобы серьёзным делом заниматься». Но ведь нужно же заниматься чем-то тем, кто никак не может вырасти. Осторожно – под катом будет много текста и неприлично много картинок.

Дискуссия вокруг Scala не стихает уже много лет, разворачиваясь в основном на поле противостояния с Java. Действительно, несмотря на общую платформу, языки разные.

Аргументы за Scala известны:

1. Scala лаконичная;
2. Scala функциональная;
3. Scala крутая и современная;

В ответ на то, что Scala медленно загибается, Мартин Одерски заявил следующее: «В 2015-м было затишье, но вот в 2016-м развитие Scala должно ускориться».

В этом посте я не буду глубоко погружаться в техническую дискуссию, есть множество специалистов, которые сделают это лучше меня. Сегодня мы поговорим о том, нужна ли Scala разработчику для саморазвития, для этого хочу предложить вам перевод статьи Matthew Casperson.

Ну и в конце дам пару ссылок на популярные статьи по теме за последние несколько лет, если вдруг вы какие-то из них пропустили.

Перевод одной из статей Бена Джонсона из серии "Go Walkthrough" по более углублённому изучению стандартной библиотеки Go в контексте реальных задач.

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

Этот пост является одним из серии статей по более углублённому разбору стандартной библиотеки. Несмотря на то, что стандартная документация предоставляет массу полезной информации, в контексте реальных задач может быть непросто разобраться, что и когда использовать. Эта серия статей направлена на то, чтобы показать использование пакетов стандартной библиотеки в контексте реальных приложений. Если у вас есть вопросы или комментарии, вы всегда можете написать мне в Твиттер — @benbjohnson.

Привет Хабр! Предлагаю вашему вниманию свободный перевод статьи «React Patterns» Майкла Чана, с некоторыми моими примечаниями и дополнениями.

Прежде всего хотел бы поблагодарить автора оригинального текста. В переводе я использовал понятие «Простой компонент» как обозначение Stateless Component aka Dump Component aka Component vs Container
Конструктивная критика, а так же альтернативные паттерны и фичи React приветствуются в комментах.

Оглавление

• Простые компоненты — Stateless function
• JSX распределение атрибутов — JSX Spread Attributes
• Деструктуризация аргументов — Destructuring Arguments
• Условный рендеринг — Conditional Rendering
• Типы потомков — Children Types
• Массив как потомок — Array as children
• Функция как потомок — Function as children
• Функция в render — Render callback
• Проход по потомкам — Children pass-through
• Перенаправление компонента — Proxy component
• Стилизация компонентов — Style component
• Переключатель событий — Event switch
• Компонент-макет — Layout component
• Компонент-контейнер — Container component
• Компоненты высшего порядка — Higher-order component

Поехали!

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

В этой статье мы рассмотрим распространённые виды утечек памяти в клиентском JavaScript. Также мы узнаем, как их обнаружить с помощью Chrome Development Tools.

Недавно на хабрахабре вышла статья о java на raspberry pi, увидев название которой было много ожиданий, а под катом оказался банальный Hello World!

Дело в том, что ко мне как раз ехала моя малинка и хотелось получить ответы на следующие вопросы:

1. Сравнима ли скорость работы java на малинке и настольном компьютере?
2. Насколько удобно работать с java на raspberry?
3. Есть ли адекватные библиотеки для работы с GPIO?

Вот на эти вопросы я и попробую дать ответы в этой статье.

Кому интересно: добро пожаловать под кат (графики и фотографий обнаженной малинки там не будет)

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

Очередной день обещал быть простым и приятным, насколько это возможно когда в очередной раз спасаешь “горящий” проект. По плану до вечера всего то надо было оживить интегральный совмещённый датчик температуры и влажности. Крошечные размеры, занимаемые им на плате, малое количество ножек и отсутствие дискретных компонентов “обвязки” позволяли надеяться на то, что имеешь дело с новейшей разработкой, а современные датчики, не смотря на маленькие размеры, отличаются умом и сообразительностью. Они без лишних вопросов выдают на выходе готовый результат. Зачастую они не просто выполняют измерения, а производят очень сложную обработку сигналов, имеют внутренние буферы для хранения данных, выходы прерываний чтобы во время разбудить микроконтроллер и много других приятных фишек. Всё это сильно облегчает задачу написания кода и сокращает требования к ресурсам управляющего микроконтроллера… Общаться с ними легко и приятно. Правда иногда приходится повозиться с большим количеством настроек. Однако, сегодня мне это не грозило, ведь передо мной всего лишь банальный ёмкостный измеритель влажности с функцией измерения температуры.