public static void main(String[] args)

Рыская по интернетам, зашел на страницу про URI и спустя несколько часов осознал, как мало я знал об этом монстре. Признаюсь, до этого я думал, что URI это либо URL, либо URN. Но это не так! Есть и другие варианты идентификации ресурса в сети.

Существует проблема: У сайта в IPFS нет возможности использовать серверные скрипты для формирования страницы. Если использовать генерацию страниц перед загрузкой то добавив новый пункт меню в каждую страницу мы изменим хеш этих страниц. Так что всю сборку страниц нужно производить силами браузера.

Обычно формируют содержание страниц при помощи JavaScript. Это знакомая технология но у неё есть свои недостатки.

Я буду использовать XSLT. Это древняя технология шаблонов которая давно встроена в браузеры но мало кто ей пользуется. Возможно потому что шаблоны заставляют писать много текста и из за путаницы с пространствами имён и множества ошибок без внятного объяснения. Также не смотря на то что есть уже XSLT 3.0 в браузерах по прежнему доступен только XSLT 1.0.

XSLT работает так:

1. Пользователь открывает в браузере XML документ.
2. В заголовке XML документ содержит ссылку на XSLT шаблон.
   

   <?xml-stylesheet href="xslt/запись.xslt" type="text/xsl" ?>

3. Шаблон в браузере на основе XML документа и других данных формирует xHTML документ.
4. Браузер отображает полученный xHTML документ.

Привязав множество страниц к одному шаблону можно менять отображаемый xHTML документ не меняя XML документы. Таким образом при смене дизайна не будет меняться хеш XML документов а значит старые их копии будут источниками для новых в IPFS.

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

Приветствую, это текстовая версия моего доклада на JPoint-2021. Как обычно я сделал упор на случаи из жизни и на повседневные вещи, используемые каждым разработчиком. Под кат приглашаются интересующиеся производительностью и им сочувствующие.

Вводная

Уверен, что вы хотя бы раз создавали пару ключей RSA, напримет, потому, что вам нужно было подключиться к GitHub, и вы хотели избежать необходимости вводить свой пароль каждый раз. Вы добросовестно следовали инструкциям по созданию SSH-ключей, и через пару минут всё было готово.

Но знаете ли вы, что именно вы делали? Углублялись ли вы в детали процесса?

Знаете ли вы, что содержится в файле ~/.ssh/id_rsa? Почему ssh создает два файла с разным форматом? Замечали ли вы, что один файл начинается со слов ssh-rsa, а другой — с -----BEGIN RSA PRIVATE KEY----- ? Вы замечали, что иногда в заголовке второго файла отсутствует часть RSA и просто написано BEGIN PRIVATE KEY?

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

В современном мире IoT, когда связь в отдаленных районах становится все более актуальной, технология LoRa (Long Range) предоставляет нам возможность создать дальнобойный, надежный, энергоэффективный и зашифрованный канал связи без необходимости иметь какую-либо сетевую инфраструктуру. 

В этой статье мы рассмотрим, как создать простой LoRa мессенджер с использованием своего протокола обмена и готовых модулей, работающих в режиме P2P (peer-to-peer) – не идеального, но интересного решения для обмена текстовыми сообщениями в условиях ограниченной инфраструктуры.

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

Выглядеть будет просто, потому что воспользуемся всем готовым :)