Пользователь технологий
В первой части темы мы познакомились с проектом Meshtastic. Узнали, что можно построить собственный радиочат на основе Mesh-сети, обычного смартфона и радиомодема.
Во второй части мы узнали о существующих фирменных решениях, о том какие заготовки для Meshtastic-модемы можно купить на Aliexpress, их отличия и особенности применения.
Если по какой-либо причине готовые изделия вас не интересуют, то в этой части мы рассмотрим материалы о том, как Meshtastic-модем собрать своими силами. Узнаем какие комплектующие вам для этого понадобятся и познакомимся с несколькими схемными решениями.
Собрать свой радиомодем совсем не сложно и под силу даже самому молодому и начинающему радиолюбителю. Интересно? Добро пожаловать под кат в третью часть.
Вы когда-нибудь задумывались над тем, что будете делать, окажись внезапно в чрезвычайной ситуации без сотовой или спутниковой связи, без интернета, без возможности вызвать помощь? Ваш телефон, при этом, ещё пару-тройку дней без электричества будет работать и, вероятно, сможет спасти вашу жизнь и жизни окружающих вас людей.
Meshtastic — это проект, который позволяет построить свою частную радиосеть с очень большим временем автономной работы, используя недорогие радио модули LoRa и экономичные микроконтроллеры серии ESP32.
Радиомодем связаны с вашим смартфоном по сети Bluetooth. Для некоторых сценариев использования смартфон вообще не требуется.
Обычно, время работы модема может составлять около недели. При использовании солнечных батарей время работы ретрансляционного узла не лимитировано.
Каждый участник вашей сети всегда может видеть местоположение и расстояние до всех остальных участников, а также, обмениваться любыми текстовыми сообщениями, отправленными в ваш групповой чат.
Проект подходит для создания экстренной сети связи в условиях ЧС, может использоваться в бытовом применении для оперативной связи и практически любого хобби, где отсутствует сотовая связь и Интернет.
Nginx состоит из модулей и именно они выполняют всю реальную работу. Стандартные модули позволяют решить большинство задач, но наступает момент, когда необходимо осуществить какие-то нетипичные действия и тогда мы либо берем сторонний модуль, либо пишем свой собственный.
При этом, даже если модуль давно написан и имеет хорошие отзывы, нет никакой гарантии, что его работа не вызовет проблем, причем, возможно, исключительно в нашей конфигурации или сборке. А Nginx, как известно, рождён для производительности, и, добавляя модули, мы не хотим этой производительности потерять. Поэтому каждая новая сборка должна завершаться отладкой и профилированием.
В недавней статье мы сняли верхний слой грунта, но чтобы локализовать возможную проблему нам придётся копать намного глубже. В самом Nginx есть режим отладки, и он действительно помогает выявлять проблемы, но в качестве профилировщика не годится, так как сам вносит приличную задержку. Поэтому нам потребуется сторонний инструмент и тут, как нельзя лучше, подойдёт dtrace.
В этой части я покажу как изначально выглядело деление пользовательского интерфейса и что из себя представляли Вид и Контроллер. Попробую рассказать почему в современных GUI библиотеках используется их объединение и какие вообще интересные решения можно найти в этой области на сегодняшний день. Ссылки на первоисточники приведены в начале первой части.
Начну с Вида. Не смотря на то, что Вид определяется как модуль, отображающий Модель – "а view is a (visual) representation of its model", на практике к Виду, как правило, просто относят все графические элементы GUI, то есть Видом считается все то, что мы видим на экране ЭВМ.
Понятно, что тут содержится некое противоречие, поскольку такие графические компоненты как меню, кнопки, тулбары служат не для отображения информации о системе, а прежде всего для управления системой. Клавиатура и мышь всегда были средством управления программой и находились в «ведомости» Контроллера (как бы его не трактовали). Поэтому кажется нелогичным и странным, что кнопки, сделанные из пластмассы, считаются элементами управления и относятся к Контроллеру, а кнопки, нарисованные на экране, и по сути выполняющие те же самые функции (производить входящие события), почему то относят к Виду.
— Не понимаю, почему люди так восхищаются этим Карузо? Косноязычен, гугнив, поёт — ничего не разберешь!
— А вы слышали, как поёт Карузо?
— Да, мне тут кое-что из его репертуара Рабинович напел по телефону.
Я осознаю, что писать очередную статью на тему Модель-Вид-Контроллер это глупо и вредно для «кармы». Однако с этим «паттерном» у меня слишком личные отношения – проваленный проект, полгода жизни и тяжелой работы «в корзину».
Проект мы переписали, уже без MVC, просто руководствуясь принципами – код перестал быть похож на клубок спагетти и сократился наполовину (об этом позже, в обещанной статье про то, как мы применяли «принципы» в своем проекте). Но хотелось понять, что же мы сделали не так, в чем была ошибка? И в течении долгого времени изучалось все, что содержало аббревиатуру MVC. До тех пор пока не встретились исходные работы от создателя – Трюгве Реенскауга…
И тогда все встало на свои места. Оказалось что фактически на основе принципов мы пере-изобретали «original MVC». А то, что зачастую преподносится как MVC, не имеет к нему никакого отношения… впрочем также как и к хорошей архитектуре. И судя по тому сколько людей пишет о несостоятельности «классического MVC», спорит о нем и изобретает его всевозможные модификации, не одни мы столкнулись с этой проблемой.
Более 30 лет собранные в MVC идеи и решения остаются наиболее значимыми для разработки пользовательских интерфейсов. Но как ни странно, несмотря на существующую путаницу и обилие противоречивых трактовок, разработчики продолжают довольствоваться информацией «из вторых рук», черпая знания о MVC из википедии, небольших статей в интернете и фреймворков для разработки веб-приложений. Самые «продвинутые» читают Мартина Фаулера. И почему-то почти никто не обращается к первоисточникам. Вот этот пробел и хотелось бы заполнить. И заодно развеять некоторые мифы.
Недавно со мной связался Эдуард Шишкин и попросил опубликовать второе интервью (что я с радостью и делаю).
С первым интервью (2010-го года) можно ознакомиться здесь.
"Хочешь ускорить запросы, построй индекс" – классический первый шаг по увеличению производительности в PostgreSQL. Вот только на практике можно встретить ситуацию, когда индексы в PostgreSQL есть, но тормоза никуда не делись. Не все индексы являются эффективными. Одна из возможных причин тормозов индексов – это отсутствие корреляции данных. Давайте поговорим о пенальти на производительность, которое дает расположение данных: почему это происходит и как это можно предотвратить.
После прочтения ряда статей (например, этой) решил перейти на современный подход с использованием Node.js при написании простых сайтов с подхода «динозавров». Ниже представлен разбор примера сборки простого статического сайта с помощью Webpack 4. Статья написана, так как инструкции с решением моей задачи не нашел: пришлось собирать всё по кусочкам.
Если вы не изучали JavaScript с самого начала, то осваивать его современную версию сложно. Экосистема быстро растёт и меняется, так что трудно разобраться с проблемами, для решения которых придуманы разные инструменты. Я начал программировать в 1998-м, но начал понимать JavaScript только в 2014-м. Помню, как просматривал Browserify и смотрел на его слоган:
Browserify позволяет делать require («модули») в браузере, объединяя все ваши зависимости
Я не понял ни слова из предложения и стал разбираться, как это может помочь мне как разработчику.
Цель статьи — рассказать о контексте, в котором инструменты в JavaScript развивались вплоть до 2017-го. Начнём с самого начала и будем делать сайт, как это делали бы динозавры — безо всяких инструментов, на чистом HTML и JavaScript. Постепенно станем вводить разные инструменты, поочерёдно рассматривая решаемые ими проблемы. Благодаря историческому контексту вы сможете адаптироваться к постоянно меняющемуся ландшафту JavaScript и понять его.
SQLite во многих случаях является удобным, незаменимым инструментом. Я уже не могу себе представить - как мы все жили без него. Тем не менее, есть некоторые неудобства при его использовании, связанные с тем, что это легкая встраиваемая СУБД.
Самое большое неудобство для меня, как Delphi-разработчика - отсутствие хранимых процедур. Я очень не люблю смешивать Delphi-код и SQL-скрипты. Это делает код намного менее читабильным, и затрудняет его поддержку.
Предлагаю свой вариант решения проблемы:
Выносим весь SQL-код в отдельный файл ресурсов, подключенный к проекту
Запросы в SQL-файле разделяем маркерами начала с идентификаторами и маркерами конца
Создаем класс - менеджер SQL-запросов. При загрузке приложения он читает SQL-файл из ресурсов и составляет из него список хранимых процедур.
В процессе работы приложения менеджер извлекает текст SQL-запроса по его идентификатору для последующей его передачи на выполнение
Пришло время использовать RT Linux.
Для периодических событий очень важна задержка начала отработки события. Точнее максимальный джиттер. Когда джитер соизмерим с периодом возникновения события, система становится непригодной для отработки периодических событий.
Хомяки приветствуют вас, друзья!
Сегодняшний пост будет посвящен тонкой науке в сфере выбора самогонных аппаратов. Если у вас в процессе дистилляции или ректификации в отборе появились хлопья, а на протяжении всей перегонки самогон имеет неприятный вкус и запах - значит что у вас руки-крюки, либо вы попались на рекламную компанию недобросовестных производителей. Сегодня мы узнаем на какие узлы конструкции в первую очередь стоит обращать внимание при покупке аппарата, какая должна быть сталь в этих шайтан машинах и какой должен стоять термоконтроллер в перегонном кубе. Уверен этот пост будет полезен не только новичкам, но и профессионалам в этом непростом ремесле.
Ранее Cloud4Y рассказал про уязвимости веб-серверов Nginx, балансировщиков нагрузки и прокси-серверов. Что-то из этого вы могли знать, а что-то, надеемся, стало полезной информацией.
Но история не закончилась. Многочисленные программы bug bounties позволяют проводить широкомасштабные исследования, благодаря которым удаётся найти реально действующие уязвимости. Проект Gixy помог найти множество неправильных конфигураций промежуточного ПО, но далеко не все. Что ещё удалось обнаружить:
Представьте, что однажды Вы приходите на любимую работу, но начальник встречает Вас нервно, напряжен как струна, и, вызвав Вас к себе, объявляет Вам, что Вы уволены. Вам это объявление портит настроение, опускает самолюбие ниже плинтуса, Вы теряетесь, не знаете, как поступить, что говорить, и о чем начинать беспокоиться в первую очередь - чем оплачивать жилье, квартиру, ипотеку или отдавать долг Сашке и т. п. Попутно Вам начальник/кадровик подсовывает в руки пустой лист бумаги и ручку и говорит написать заявление. Туман в голове, дрожащими руками Вы начинаете выводить на белоснежном листе «генеральному директору ООО «Компания» Иванову И. И., заявление» ниже «прошу уволить меня по собственному желан…» СТОП. Какая-то ерунда получается. Может сказать чудаку начальнику, что у меня желания-то увольняться совсем нет, и зачем тогда писать это заявление, если я уже уволен? Если я уволен – отдайте трудовую книжку, зарплату и отпустите восвояси. Непонятно…
Поделившись своими сомнениями с кадровиком, Вы замечаете, что Инспектор по кадрам багровеет и рассказывает, что Ваши коллеги-соратники уже написали заявление и советует Вам сделать то же самое - это в Ваших же интересах – «иначеуволимпостатьеиотправимсволчьимбилетом».
Вам становится еще страшнее от ее уверенности, но у Вас уже просыпается любопытство, подбадриваемое логикой и верой в справедливость - «За что уволите, я ж ничего не нарушал(а)?». Инспектор, не ожидая такого поворота, багровеет еще больше и выбегает из кабинета. Немного погодя, у Вас уже разговор с начальником отдела кадров и Вашим начальником. Они участливо с Вами беседуют, но припоминают Вам Ваши старые грешки: опоздания, болезни без бюллетеня пусть даже с разрешения начальника (этожепрогул!) и убедительно описывают Вашу низкую квалификацию, не выполнение Вами поручений руководителя, невыполнение плана продаж/обзвонов и т. п. и повторно убеждают Вас, что заявление – лучший вариант. Вы послушно отправляетесь писать заявление на увольнение. Вроде все логично и ситуация знакома многим, но есть три момента, о которых обычно забываем(или не знаем) при оценке того, что Вам говорят. С тех пор, как у нас в стране отменили крепостное право многое изменилось и государство больше защищает работников, чем работодателей и при любых спорах действует презумпция невиновности работника. Именно работодатель обязан оправдываться и доказывать, что он все корректно сделал и оформил. Допустил малейшее нарушение - отмена увольнение и оплата всего времени с момента незаконного увольнения.