
История
29 постов
29 постов
13 постов
34 поста
35 постов
29 постов
7 постов
8 постов
39 постов
6 постов
21 пост
8 постов
6 постов
24 поста
3 поста
4 поста
Приветствую! В этой статье я бы хотел уделить внимание такой вещи как шифрование трафика на Linux системах. Наверное, каждый из нас прекрасно понимает, насколько важна защита нашей приватности. Ведь в эпоху, когда многие компании собирают данные, а иногда хакеры могут перехватить наш трафик, это становится особенно важно. Просто необходимо позаботиться о безопасности своих данных. Например, быть уверенным, что какая-либо корпоративная сеть не прослушивается злоумышленниками. Информационная безопасность сегодня — это не просто мода, а насущная необходимость. Постоянно растет киберпреступность, и защита трафика от перехвата — это основной аспект цифровой жизни человека или бизнеса.
Эта часть - вторая, первую вы можете прочитать по ссылке. А в этой части мы рассмотрим что такое прокси и какие типы бывают, что такое VPN, как устроено сквозное шифрование.
И соответственно, в этой статье не будет упоминаться то, про что я уже писал в первой. Начнем, господа присяжные заседатели!
Прокси-сервер — это промежуток между клиентом и сервером. Он обеспечивает скрытие IP-адреса, поэтому сторонним лицам намного сложнее отследить местоположение пользователя. Также он помогает настроить доступ к сайтам — например, к каким-то ограничить, или даже прослеживать и мониторить трафик пользователей. За счет кеширования данных страницы могут загружаться быстрее.
Прокси-сервер действует так:
Клиент -> провайдер -> прокси-сервер -> сервер
То есть провайдер знает, какой у пользователя IP и какой у него запрос, но сервер не будет знать пользовательский IP-адрес.
Прокси-сервер — это машина, которая содержит прокси IP-адреса.
IP-адрес прокси — это индивидуальный IP-адрес, который используется для сокрытия вашего реального адреса.
Прокси-сервер обрабатывает ваши запросы, но скрывает множество идентифицирующей информации. В ее числе исходный IP-адрес, геолокация, откуда пришел запрос, данные операционной системы (ОС) и многое другое. В общем, он помогает предотвратить легкое отслеживание вас третьими лицами. Работа прокси-сервера осуществляется на уровне приложений модели OSI (L7).
Существует много разных типов прокси, которые подразделяются по разным типам протоколов, анонимности, размещения.
Если говорить про типы размещения — то это банально централизованный и децентрализованный прокси. Тут все понятно — при централизованном типе прокси-сервера находится в одном центре, которые обслуживают сразу много клиентов, а при распределенном — прокси-сервера находятся в разных локациях, которое позволяет равномерно распределить нагрузку, и при случае падении одного сервера, другие прокси сервера останутся рабочими (а в централизованном типе с этим возникнут проблемы).
По анонимности и конфиденциальности уже поинтереснее. Есть прозрачный — никаких настроек, весь трафик с клиента сразу маршрутизируется на прокси. Данные пользователя не изменяются, IP-адрес не скрывается. Быстро, экономно но не безопасно. Противоположность прозрачному — анонимный. Он уже изменяет IP-адрес клиента, но он не скрывает, что используется прокси, и сайты могут понять, что клиент использует прокси, но не больше. Еще более безопасным считаются искажающие прокси — они меняют IP адрес в точности как и анонимный, но уже скрывают факт использования прокси, то есть сервер может понять что трафик идет через дополнительный шлюз, но сам клиент остается скрытый. И последний тип — это приватный. Полностью скрывают данные о пользователе и постоянно меняют IP-адрес подключения.
Ну и перед тем, как мы затронем тему типов прокси по протоколу, стоит также рассказать о том, что прокси также могут различаться и по уровню доступности:
Публичные — открытые, бесплатные, но могут быть медленными, небезопасными и ненадежными. Если найти какой-то сайт с бесплатными прокси-серверами, то там будут именно эти с вероятностью 90%.
Приватные — платные, но быстрее и безопаснее публичных.
Выделенный — то есть уже целый высокопроизводительный сервер с выделенными ресурсами. Они позволяют настроить прокси, то есть например сделать возможность использования только одним клиентом или сделать черный список клиентов.
Прозрачные — мы уже говорили, просто маршрутизация с порта клиента на порт прокси-сервера.
Общие — то есть доступные определенной группе, например сотрудникам компании. Не так надежны как приватные, но обеспечивают баланс между доступностью и производительностью.
Прокси удобны, позволяют контролировать и мониторить трафик, а также могут обеспечить базовую анонимность. Стоит задеть тему различий с VPN:
Прокси это L7, самый высокий уровень сетевой модели OSI, когда как VPN — это L3 или L4.
В VPN могут использовать криптографические алгоритмы для обеспечения шифрования трафика и набор ключей.
Стоимость VPN обычно дороже прокси.
Прокси обычно быстрее VPN
А теперь наконец перейдем к типам прокси по протоколам.
Данный тип прокси работает с HTTP-запросами. В основном для базового серфинга - то есть кеширования страниц, настройки доступа к сайтам. Основное применение он находит в корпоративных сетях, для ограничения сотрудников (самый простой пример — блокировка доступа к социальным сетям).
HTTP-прокси существует как звено в цепи между клиентом и сервером. То есть запрос от клиента идет не напрямую на сайт, а через прокси, который уже от своего имени отправляет запрос серверу.
Тоже самое, что и HTTP, но более безопасный. HTTPS гарантирует безопасное соединение между клиентом и сервером, защищает данные от сниффинга. В основном его используют когда важна безопасность и сохранность данных, а не просто веб-серфинг.
Мы уже обсуждали SSL/TLS протокол выше. Этот тип прокси сервера создает только одно TCP-соединение. В HTTP-proxy создается два соединения — от клиента к прокси и от прокси до сервера. Но SSL работает по другому: после запроса на сервер, прокси создает запрос подключения на сервер и создает TCP-канал.
Преимущество данного типа прокси в том, что его можно использовать как и для доступа к защищенным (HTTPS) и незащищенным (HTTP) серверам.
SOCKS — SOCKets Secure. Специальный протокол для работы с интенсивным трафиком, например потоковая загрузка/передача данных или для P2P.
SOCKS использует TCP соединение, то есть все пакеты гарантированно будут доставлены. При использовании этого типа прокси интернет-трафик маршрутизируется через прокси-сервер по TCP от имени клиента.
SOCKS, как большинство прокси, скрывает IP адрес клиента, гарантируя базовую конфиденциальность.
Здесь я рассмотрю прокси-сервер Squid и как его можно установить за пару шагов.
Squid — это один из самых популярных HTTP/HTTPS прокси-серверов с возможностью перенаправления и кэширования трафика. Он скрывает IP адреса клиентов, кэширует веб-страницы, да и в принципе довольно быстрый прокси...
ЧИТАТЬ ДАЛЕЕ ↩ (без регистрации и СМС)
Материал получился достаточно объемным и все подробности, к сожалению, не влезли :(
Написано специально для Timeweb Cloud и читателей Пикабу. Больше интересных статей и новостей в нашем блоге на Хабре и телеграм-канале.
Хочешь стать автором (или уже состоявшийся автор) и есть, чем интересным поделиться в рамках наших блогов — пиши сюда.
Облачные сервисы Timeweb Cloud — это реферальная ссылка, которая может помочь поддержать авторские проекты.
Автор текста: akibkalo
Сегодня я буду рассказывать кратко о странной версии Windows (рука не поднимается сказать «Windows 11», так как это не совсем правда) – релизе zn_release на базе сборки 10.0.25398.1, на которой выходил лишь Windows Server 23H2 (только Core) и Azure Stack HCI 23H2 (тоже только Core).
Итак, для начала благодарности за данный материал форуму MyDigitalLife, где активно обсуждаются варианты вивисекции ОС Microsoft, и особенно xinso, который тестирует каждую сборку каждого издания на каждом языке и делится своим опытом, пускай и довольно своеобразно. Мастер, спасибо тебе за ценный опыт. Тем, кто не хочет читать целиком, в самом конце статьи дана ссылка на конструктор для сборки. Публикация готовых образов будет пиратством, что правилами запрещено, так что если вам будет интересно просто попробовать эту сборку, ставьте лайк и пишите мне в ПМ, дам готовый образ для установки (русский и английский интерфейсы включены в образ, остальные языки в виде дополнительных языковых пакетов).
Если вы не следите внимательно за выходами Windows 11, и не читали мою статью «Все о версиях Windows 11», то можете быть не в курсе, что официально выходили следующие версии:
Windows 11 21H2 — на базе сборки 10.0.22000.x ядра co_release (Cobalt);
Windows 11 22H2 — на базе сборки 10.0.22621.x ядра ni_release (Nickel);
Windows 11 23H2 — на базе сборки 10.0.22631.x того же ядра ni_release (Nickel);
Windows 11 24H2 — на базе сборки 10.0.26100.x ядра ge_release (Germanium).
Более того, версия 23H2 особо от 22H2 не отличается, имеет то же ядро и общие обновления. По сути, отличие между ними в пакете, включающим малость нового функционала. Вообще обе версии довольно неудачны в плане производительности и не особо популярны у геймеров.
Версия 24H2 на ядре Germanium сборки 10.0.26100.х в продажу пойдет осенью, сейчас доступна OEM производителям и инсайдерам. О ней мы знаем два интересных факта – она быстрее чем та, что на ядре Nickel, и она не работает на старых компьютерах, процессор которых не поддерживает SSE4.2.
В промежутке между ядрами Nickel и Germanium было еще одно ядро Zink, на базе которого выходили Core издания Windows Server 23H2 с номером сборки 10.0.25398.x. Клиентских ОС на базе этого ядра не выпускалось. Однако, внутри корпорации сборки Windows 11 собирались, более того, файлы для изданий Windows 11 доступны с UUPDump (например Microsoft-Windows-EditionPack-Professional-Package.ESD и Microsoft-Windows-EditionSpecific-Professional-Package.ESD). И эти сборки по тестам быстрее чем и Nickel и Germanium, работают на старых процессорах, да и вообще интересны! Дальше я расскажу, как собирать разные издания Windows 11 версии 10.0.25398.x на базе файлов UUPDump, предложу ссылку на загрузку конструктора для самостоятельной сборки, расскажу о разных тонких моментах.
Перед тем как начинать сборку образа заметим, что хотя Microsoft и не выпускала Windows 11 на базе ядра Zink, в списке изданий, на которые будут ставиться обновления для Windows Server 23H2 по странному стечению обстоятельств входит издание Windows 11 Professional, а значит, и все другие издания на его базе, переключение на которые достижимо сменой серийного номера: Professional Workstation, Enterprise, IoT Enterprise (рекомендую его, там разрешены две RDP сессии без патчей) и другие.
Список тех ОС, которые согласно языку Microsoft попадают под assemblyIdentity name="microsoft-windows-professionaledition", на которые можно будет ставить обновления без их модификации можно увидеть так:
Если в процессе реконструкции Windows 11 на этом ядре вы выберете другое издание, то обновления придётся вручную модифицировать перед установкой. Пример модифицированных обновлений есть в конструкторе в папках 25398.950 и 25398.1009.
Есть, однако, еще один нюанс. Microsoft выкладывает все системные файлы для сборки изданий Windows 11 (в том числе и Evaluation, EnterpriseG, все кроме LTSC), однако, не предлагает языковых пакетов для клиентских ОС.
Языковые пакеты для серверных ОС, разумеется, присутствуют (всё же это издание Windows Server):
А вот клиентских пакетов, увы нет. И создать без них Windows 11 невозможно. Однако, ура, ура, разные сборки в пределах ядра не сильно отличаются друг от друга, и мы можем взять клиентский языковой пакет от сборки 10.0.25393.1 доступной на UUPDump:
Слегка модифицировав MUM файлы языкового пакета 25393.1 мы заставим его работать с ядром 25398.1. Все модифицированные языковые пакеты доступны по ссылке на конструктор, данной выше в файле 25398 languagepacks.zip.
Увы, Microsoft, выпуская обновления для Windows Server 23H2 хотя в них и включает возможность установки на Windows 11, но вспоминает лишь английские версии ОС. Если вы соберете русскую версию ОС, установка обновлений зачастую заканчивается неудачно, приходится пользоваться модифицированными обновлениями.
Предлагаемый в конструкторе скрипт 25398.1_Neutral_to_Client_amd64_38in1_26100_License может создать любое издание (в том числе EnterpriseG или LTSC) на любом языке, но я рекомендую при сборке остановиться на английском языке и издании Professional или Enterprise (что делается редактированием файла Create.cmd). Для создания английской версии следует скопировать английский языковой пакет Microsoft-Windows-Client-LanguagePack-Package-amd64-en-us.esd в папку files\lang, скачать языковые пакеты в langFeature\en-us по аналогии с fr-fr и языковые пакеты Features on Demand в FOD\en-us (список для каждого языка есть в файле FOD-Lang.txt).
Рекомендованные мной настройки (модифицируйте файл Create.cmd): TARGET=Enterprise, LANG=en-US, EDGE=without (доставите потом последний вручную), NETFX3=without (будет проще если доставите после). В целом, скрипт может установить и LTSC (TARGET=EnterpriseS), и EnterpriseG и даже Starter. На любом языке. Но только для русского, английского и французского я положил скачанные с UUP файлы. Для других следует положить аналогично и изменить в файле Create.cmd параметр LANG. C .NET Framework я разобрался, в том числе и русифицированной ОС, в образах интегрированы следующие версии (более новое ставится штатно поверх):
Я не буду долго дискутировать о процессе, сам скрипт работает более часа на быстром диске, создавая install.wim. Если вам необходим загрузочный ISO образ, то install.wim следует поместить вместо одноименного от Windows Server 23H2 и пересобрать образ. В моем случае скриптом я создал Windows 11 Professional.
Дальше я могу легко сменить издание на Enterprise, просто заменив серийный номер (файлы лицензии в конструкторе взяты от Windows 10 21H2). И могу спокойно установить обновления. Через Windows Update кумулятивные обновления могут не засекаться, однако, если зайти на UUPDump, то можно скачать и установить. На данный момент последнее обновление 25398.1085. На издание Enterprise обновление ставится онлайн без проблем:
Далее я добавлю русский язык интерфейса, установив модифицированный языковой пакет. У меня не вышло сделать это онлайн, пришлось загрузиться с установочного образа и добавить его оффлайн, и для тех кто не будет самостоятельно собирать образ, а скачает мой, интегрировал в образ. Для того чтобы изменить все региональные настройки (включая язык интерфейса) на русский, воспользовался тем же dism с ключом /SetAllIntl:ru-RU. Вуаля:
После обновления до LCU 25398.1085 вижу установленных два обновления – SSU и LCU, которые были в одном MSU пакете Windows11.0-KB5041573-x64.msu выпушенном 13.08.2024. Пакет без модификаций.
Обращу внимание сразу на то, что в кумулятивных обновлениях Microsoft обновляет лишь английский языковой пакет. Если вы поставили любой другой язык, после обновления в Журнале событий пойдут предупреждения о ненайденных языковых пакетах, и система будет переключаться на английский по обновленным пакетам (в первую очередь панель Настройки), для русской версии следует оставаться на 25398.1 или использовать кастом обновления.
Да, это поделка на коленке, её можно и нужно допиливать, что-то может не работать. Например, я не мастер локализации интерфейса, и возможно не включил в образ какие-то штатные компоненты, ответственные за русский язык, - нужно внимательно изучить, возможно, следует несколько модифицировать порядок шагов русификации, я не эксперт по локализации образов, сам всегда пользуюсь англоязычным. Опциональные компоненты ОС не ставятся онлайн, если нужно включить какую-то компоненту, придется делать это оффлайн из Dism. Неудобно. Возможно, кто-то это допилит. Моя задача была показать принцип, дать конструктор желающим.
Согласно отчетам на форуме MDL, многие китайские геймеры, использующие Windows, выбирают именно эту сборку. И в ряде тестов она обходит все остальные. Буду рад услышать комментарии от тех, кто протестирует.
Подписывайтесь, ставьте лайк, запрос за образами в ПМ, и пишите комментарии, чего отдельно хотели бы увидеть в следующих статьях по разным поделкам Microsoft!
Написано специально для Timeweb Cloud и читателей Пикабу. Больше интересных статей и новостей в нашем блоге на Хабре и телеграм-канале.
Хочешь стать автором (или уже состоявшийся автор) и есть, чем интересным поделиться в рамках наших блогов — пиши сюда.
Облачные сервисы Timeweb Cloud — это реферальная ссылка, которая может помочь поддержать авторские проекты.
Автор текста: CyberexTech
Привет, Пикабу!
В этой статье я хочу описать свой опыт разработки такого простого, но в тоже время самого используемого элемента «Умного дома». Речь пойдет о модуле управления освещением. Забегая вперед, хочу сказать, что данный проект был реализован еще в 2021 году, но в настоящее время потребовалась реализация еще одного модуля. Я решил совместить приятное с полезным, дополнительно обновить прошивку устройства и «перепроектировать» данный модуль с помощью современного ПО и само собой — поделиться с вами. Если стало интересно, то добро пожаловать под кат.
Домашней автоматизацией я занимаюсь давно и застал те времена, когда еще не было доступных микроконтроллеров с беспроводной коммуникацией на борту (типа ESP8266), в основном использовались проводные решения на базе 1-Wire. И мой «Умный дом» не стал исключением.
Каждый начинающий «строитель» «Умного дома» понимает, что первым делом нужно научиться включать и выключать свет, чтобы эффектно удивлять друзей, управляя освещением со смартфона. В те времена это казалось магией :) Вот и я, закупившись на Алиэкспрессе поддельными двухканальными 1- Wire свичами DS2413P, решил реализовать управление светом. В итоге была собрана плата управления на базе купленных свичей и симисторным управлением нагрузкой. Данное устройство надежно проработало аж до 2021 года. Но летом того же года была жуткая гроза и по витой паре интернет провайдера прилетел мощный разряд, который унес в электронный рай сетевую карту сервера, USB 1-Wire адаптер, ну и плату управления освещением с эффектным взрывом симистора. Тогда я подумал, что пора завязывать с проводными решениями ибо гирлянда сгоревших устройств ни на секунду меня не радовала и я принялся за разработку беспроводного модуля управления освещением.
Условно мы можем разделить модуль на три сегмента:
Система питания;
Контроллер управления;
Система силового управления.
При проектировании принципиальной схемы устройства будем придерживаться «золотого» принципа: чем проще — тем лучше, а значит — надежнее. Поэтому в качестве системы питания будет реализована схема на базе экономичного импульсного преобразователя напряжения LNK306GN, который доказал свою надежность временем и работой в аномальных условиях.
Краткая информация о LNK306GN:
LNK306GN — это понижающий преобразователь с наименьшим количеством внешних элементов.
Серия микросхем LinkSwitch-TN специально разработана для замены всех неизолированных источников питания с линейным питанием и питанием от конденсаторов в диапазоне выходного тока менее 360 мА при равной стоимости системы, обеспечивая гораздо более высокую производительность и энергоэффективность.
Устройства LinkSwitch-TN объединяют в монолитной IC силовой полевой МОП-транзистор с напряжением до 700 В, генератор, простую схему управления включением/выключением, высоковольтный импульсный источник тока, генератор частот, схему ограничения тока и схему отключения при перегреве.
В качестве «мозга» нашего устройства, будем использовать микроконтроллер от компании Espressif Systems ESP8266. А для силового управления нагрузкой, то есть нашими лампочками, будем использовать связку оптопары MOC3052M и симистора BT136-600. Почему не реле? — спросите вы, ну не люблю я реле, они щелкают и габаритные. Ниже можно видеть результат разработки принципиальной схемы устройства. Для разработки схем и печатных плат я использую открытое ПО KiCAD.
Принципиальная схема модуля:
Как я уже говорил ранее, источник питания реализован на высоковольтном импульсном преобразователе LNK306GN, который позволяет максимально упростить схему источника питания. На выходе источника формируется напряжение в 3,3 В, данное напряжение устанавливается обратной связью, которая организована с помощью резистивного делителя напряжения R4 и R5. Данная схема питания не имеет гальванической развязки с сетью, поэтому нужно обеспечить эффективную изоляцию платы для исключения поражения электрическим током. Первоначальный запуск устройства должен выполняться с последовательно подключенной нагрузкой (лампа накаливания 60 Вт) в цепи питания, чтобы исключить повреждения в случае ошибки при монтаже компонентов.
Трассировка платы:
Визуализация печатной платы:
Хочется добавить, что данная плата разрабатывалась с учетом современных реалий, здесь изменен форм-фактор микросхемы LNK306GN на SOP-7 в старой версии модуля используется тип корпуса DIP-7.
На тот момент, плата изготавливалась по канонам DIY, с помощью фоторезиста и фотошаблона. Но в настоящее время я пользуюсь для изготовления прототипов плат лазерным методом.
Активация фоторезиста с помощью фотошаблона:
Плата прототипа модуля после монтажа электронных компонентов:
Разработка корпуса устройства выполнялось в открытом ПОFreeCAD. Корпус довольно тривиальный и не содержит сложных элементов.
Визуализация корпуса с моделью платы:
Далее модель корпуса распечатывается на 3D принтере, в качестве материала печати используется HIPS пластик.
Устройство в собранном виде:
AirTag для сравнения габаритов устройства:
Разработка микро ПО устройства велась в средеArduino IDE, обновленная версия реализована на моей, ставшей уже базовой, прошивке для умный устройств. Для улучшения пользовательского опыта, в прошивке применены следующие технологии:
Captive portal;
Multicast DNS;
MQTT Auto Discovery;
SSDP.
Captive portal— это сервис, на который принудительно перенаправляется пользователь, который выполнил подключение к устройству. Данный сервис работает только в режиме «точки доступа» при первоначальной конфигурации устройства. При отсутствии сетевого соединения или при первоначальной настройке, устройство создает беспарольную точку доступа с именемCYBEREX-Light. При подключении к данной точке доступа, пользователь автоматически будет перенаправлен на страницу авторизации для выполнения первоначальной конфигурации устройства. Для конфигурации устройства необходимо ввести пароль по умолчанию "admin".
Ниже приведены несколько скриншотов веб интерфейса устройства.
Страница входа:
Главная страница с элементами управления:
Конфигурация обмена по MQTT протоколу:
Multicast DNS — данный сервис используется для поиска устройств по доменному имени в локальной сети без использования предварительно настроенного DNS сервера. Другими словами, пользователь может получать доступ к устройству без необходимости ввода IP адреса. Ниже пример использования данного сервиса, где доступ к устройству выполняется с помощью его локального имени 11395386.local.
Страница конфигурации управления устройством через API:
Как вы можете видеть на скриншоте, в устройстве реализован доступ управления каналами модуля по API. Данная функция необходима для прямого взаимодействия с устройством без посредников в виде MQTT сервера или системы «Умного дома». Эту функцию можно использовать для подключения беспроводных выключателей, пример реализации в одном из моих проектов:
Демонстрируемый беспроводной выключатель также реализован на ESP8266, в качестве элементов питания использует две батарейки формата ААА. Данный выключатель проработал уже три года на одних элементах питания, благодаря режиму DeepSleep.
А еще функция данного API применяется в моей «умной колонке» (статья первая,статья вторая) для управления освещением. Ниже пример кода для реализации прямого управления с помощью «умной колонки»:
Код управления по API | Python:
elif cmd == 'lightON':
try:
contents = urllib.request.urlopen("http://11395386.local/?page=status&apikey=UkFA7").read()
response0 = json.loads(contents)
if response0['c1'] == 'Off1' and response0['c2'] == 'Off2':
text = "Включила свет"
if response0['c1'] == 'On1' and response0['c2'] == 'Off2':
text = "Первый светильник уже включен, включила второй!"
if response0['c1'] == 'Off1' and response0['c2'] == 'On2':
text = "Второй светильник уже включен, включила первый!"
if response0['c1'] == 'On1' and response0['c2'] == 'On2':
text = "Свет уже включен! Но я могу выключить, если попросите!"
if response0['c1'] == 'Off1':
response2 = requests.get('http://11395386.local/?page=control&apikey=UkFA7&switch=1')
if response0['c2'] == 'Off2':
response2 = requests.get('http://11395386.local/?page=control&apikey=UkFA7&switch=2')
tts.va_speak(text)
except:
tts.va_speak("Сожалею, но возникла ошибка, попробуйте позже!")
elif cmd == 'lightOFF':
try:
contents = urllib.request.urlopen("http://11395386.local/?page=status&apikey=UkFA7").read()
response0 = json.loads(contents)
if response0['c1'] == 'Off1' and response0['c2'] == 'Off2':
text = "Свет уже выключен! Но я могу включить, если попросите!"
if response0['c1'] == 'On1' and response0['c2'] == 'Off2':
text = "Второй светильник уже выключен, выключила первый!"
if response0['c1'] == 'Off1' and response0['c2'] == 'On2':
text = "Первый светильник уже выключен, выключила второй!"
if response0['c1'] == 'On1' and response0['c2'] == 'On2':
text = "Выключила свет!"
if response0['c1'] == 'On1':
response2 = requests.get('http://11395386.local/?page=control&apikey=UkFA7&switch=1')
if response0['c2'] == 'On2':
response2 = requests.get('http://11395386.local/?page=control&apikey=UkFA7&switch=2')
tts.va_speak(text)
except:
tts.va_speak("Сожалею, но возникла ошибка, попробуйте позже!")
Интеграция устройства в систему «Умного дома» реализована с помощью MQTT Auto Discovery.
MQTT Auto Discovery— сервис, позволяющий максимально упростить интеграцию нашего устройства в систему «Умного дома». В моем случае, в качестве системы «умного дома», я использую Home Assistant, поэтому сервис MQTT Auto Discovery адаптирован именно под неё. Ниже код реализации MQTT Auto Discovery в микро ПО устройства:
Код реализации MQTT Auto Discovery | С++:
void send_mqtt(String tops, String data, String subscr){
// Анонсируем объекты для Home Assistant [auto-discovery ]
// Анонсируем объекты один раз при успешном подуключении и при запуске устройства
// if(!annonce_mqtt_discovery){
mqqt_d_annonce("CL1", "c1", "On1", "Off1");
mqqt_d_annonce("CL2", "c2", "On2", "Off2");
mqqt_d_annonce("CL3", "c3", "On3", "Off3");
annonce_mqtt_discovery = true;
// }
// Отправляем данные
client.publish(tops.c_str(), data.c_str());
client.subscribe(subscr.c_str());
}
void mqqt_d_annonce(String namec, String cn, String on_d, String off_d){
String top = String(settings.mqtt_topic) +"/jsondata";
String control = String(settings.mqtt_topic) +"/control";
char jsonBuffer[1024] = {0};
DynamicJsonDocument chan1(1024);
chan1["name"] = namec;
chan1["state_topic"] = top;
chan1["command_topic"] = control;
chan1["payload_on"] = on_d;
chan1["payload_off"] = off_d;
chan1["state_value_template"] = "{{ value_json."+cn+" }}";
serializeJson(chan1, jsonBuffer, sizeof(jsonBuffer));
String top_to = "homeassistant/light/"+cn+"/config";
client.publish(top_to.c_str(), jsonBuffer, true);
}
После успешного подключения устройства к сети и настройки MQTT соединения, в «объектах» Home Assistant появятся объекты нашего устройства, пользователю останется только настроить карточку объектов на панели управления, чтобы иметь возможность управлять данным модулем. Ниже приведен пример кода карточки объектов:
Пример кода карточки объектов:
type: horizontal-stack
cards:
- show_name: true
show_icon: true
type: button
tap_action:
action: toggle
entity: light.cl1
name: Свет 1
show_state: true
hold_action:
action: more-info
- show_name: true
show_icon: true
type: button
tap_action:
action: toggle
entity: light.cl2
name: Свет 2
show_state: true
hold_action:
action: more-info
- show_name: true
show_icon: true
type: button
tap_action:
action: toggle
entity: light.cl3
name: LED
show_state: true
hold_action:
action: more-info
В результате карточка объектов будет выглядеть следующим образом:
Осталось упомянуть о последнем сервисе SSDP.
Чтобы как-то «повелевать» всем зоопарком моих умных устройств, был реализован данный сервис.
SSDP (Simple Service Discovery Protocol) — сетевой протокол, основанный на наборе протоколов Интернета, служащий для объявления и обнаружения сетевых сервисов. SSDP позволяет обнаруживать сервисы, не требуя специальных механизмов статической конфигурации или действий со стороны серверов, таких как DHCP или DNS.
Для моего удобства, я написал мобильное приложение, которое позволяет в три нажатия обнаружить и сконфигурировать устройство без лишних хлопот и похода в роутер. Ниже представлены скриншоты приложения, ссылка на приложение будет размещена в конце статьи.
Приложение для поиска устройств в сети:
Дабы не исключать классическую схему управления освещением с помощью обычного выключателя, который обычно встраивается в стену, в устройстве также реализован вход (J5) для подключения аппаратного выключателя. Данное решение позволяет без дополнительных переделок интегрировать модуль в существующую систему освещения.
Ну что ж, давайте подведем итоги. В итоге у нас получилось простое, но эффективное и относительно компактное устройство для управления освещением, с возможностью работы как в автономном режиме, так и в составе «Умного дома». Данное устройство разрабатывалось, прежде всего, для управления светодиодным освещением, но примененные силовые симисторы позволяют коммутировать осветительную нагрузку до 300Вт на канал, без ощутимого нагрева силовых элементов.
На этом можно и завершить статью. Надеюсь, мой опыт будет вам полезен. Если у вас есть замечания, предложения или вы хотите поделиться подобным опытом, то добро пожаловать в комментарии! Если статья вам понравилась, то поддержите её стрелочной вверх. Всем добра, здоровья и спасибо за внимание!
Ссылки к статье:
Написано специально для Timeweb Cloud и читателей Пикабу. Больше интересных статей и новостей в нашем блоге на Хабре и телеграм-канале.
Хочешь стать автором (или уже состоявшийся автор) и есть, чем интересным поделиться в рамках наших блогов — пиши сюда.
Облачные сервисы Timeweb Cloud — это реферальная ссылка, которая может помочь поддержать авторские проекты.
Автор текста: ProstoKirReal
Приветствую, коллеги! Меня зовут ProstoKirReal, и сегодня я хочу обсудить с вами физический уровень (L1) модели OSI. Понимание этого уровня является основополагающим для всех, кто только начинает свой путь в сетевых технологиях.
Физический уровень (Physical Layer) — это первый и самый низкий уровень модели OSI. Он отвечает за передачу необработанных битов данных по физическим средствам связи, таким как кабели и радиоволны. Этот уровень определяет электрические, механические, процедурные и функциональные характеристики для активации, поддержания и деактивации физических соединений между конечными системами.
Для начала необходимо понять, а что же такое бит данных. Я в первые месяцы работы очень часто путался в понятиях бит и байт.
Бит и байт — это две основные единицы измерения информации в компьютерных системах. Разница между ними заключается в следующем:
Определение: бит (bit) является наименьшей единицей информации в компьютерных системах.
Значение: может принимать одно из двух значений: 0 или 1. Эти значения часто интерпретируются как «включено» или «выключено», «истина» или «ложь».
Использование: используется для представления двоичной информации и операций на уровне аппаратного обеспечения.
Определение: байт (byte) состоит из 8 битов.
Значение: может представлять 256 различных значений (от 0 до 255 в десятичной системе или от 00 до FF в шестнадцатеричной системе).
Использование: широко используется для представления данных, таких как символы в текстовых файлах. Например, каждый символ в стандарте ASCII кодируется одним байтом.
Примерное сравнение:
Бит: 0 или 1
Байт: 8 битов (например, 01101010)
Для запоминания есть старая шутка:
Штирлиц поругался с посетителем бара и вышел с ним 1 на 1. На выходе он увидел 8 человек с битами. «Один байт равно 8 бит», — подумал Штирлиц
Выше я писал о двоичной и шестнадцатеричной системе. А для чего они?
На двоичной системе общаются между собой различные сетевые устройства, компьютеры и т.д.
А что же делать нам обычным людям? Даже простые данные в двоичной системе выглядят очень громоздко.
К примеру предложение «Hello, world!» выглядит как 01001000 01100101 01101100 01101100 01101111 00101100 00100000 01110111 01101111 01110010 01101100 01100100 00100001.
Для повышения читаемости таких массивов данных используют шестнадцатеричную систему. К примеру, предложение «Hello, world!» выглядит как 48 65 6C 6C 6F 2C 20 77 6F 72 6C 64 21.
Уже читабельнее?
То есть 1 бит – 0, 1 байт – 01001000, в 16-ричной 1 байт – 48.
Шестнадцатеричная система счисления — это удобный, компактный и общепринятый способ представления двоичных данных в компьютерных сетях и других областях информатики. Она позволяет инженерам и программистам эффективно работать с данными, обеспечивая при этом легкость преобразования и улучшенную читаемость.
Удобство преобразования: простое преобразование между шестнадцатеричной и двоичной системами.
Краткость записи: значительно более короткие записи по сравнению с двоичной системой.
Повышенная читаемость: легче для восприятия и анализа при работе с низкоуровневыми данными.
Принятость в стандартах: широко используется в сетевых и компьютерных стандартах.
Сложно? Еще немного и доберемся до L1.
Еще одно понятие, которое нам будет необходимо для понимания.
Пакет данных —это набор информации, который передается между устройствами в компьютерных сетях. Он содержит данные, такие как текст, изображения, аудио или видео, и информацию о том, куда и откуда эти данные должны быть отправлены. Пакеты данных играют ключевую роль в передаче информации через сети.
Пакет служит нам для передачи информации от компьютера к компьютеру. Вообще это отдельная тема для разговора, после модели OSI займусь написанием статьи про пакеты данных.
Если вкратце, то данные, которые нам необходимо передать по сети, делятся на несколько частей. Далее к этим данным добавляется специальный заголовок (необходимый для передачи пакетов по сети) и этот пакет с данными передается по сети в виде электрических или световых сигналов.
Итак, про L1 уровень.
За преобразование битов данных на первом уровне отвечают сетевые карточки в компьютерах и серверах, за передачу пакетов по сети используются SFP модули в таких сетевыех устройствах, как коммутаторы, маршрутизаторы и т.д.
Передача битов: Физический уровень определяет способ передачи битов данных по физическому носителю, будь то медные кабели, оптоволоконные кабели или беспроводные каналы.
Медные кабели передают информацию с помощью электрических сигналов, бывают 1G и 10G медные кабели, типа витая пара. Я был удивлен о наличии 10G меди.
Оптоволоконные кабели передают информацию с помощью световых сигналов.
Беспроводные соответственно передают информацию без проводов, по средством радиоволн.
Модуляция и демодуляция: Преобразование цифровых данных в аналоговые сигналы и обратно.
Модуляция и демодуляция — это процессы, используемые для передачи цифровых данных через аналоговые среды, такие как радиоволны, телефонные линии или оптоволоконные кабели. Эти процессы играют ключевую роль в современных коммуникационных системах, включая интернет, мобильные сети и телевидение.
Модуляция — это процесс преобразования цифровых данных (битов) в аналоговые сигналы, которые могут быть переданы через аналоговую среду.
Демодуляция — это процесс обратного преобразования аналоговых сигналов в цифровые данные. Демодулятор принимает модулированный аналоговый сигнал и извлекает из него оригинальные цифровые данные.
Эффективная передача данных: модуляция позволяет передавать цифровые данные через аналоговые среды, такие как телефонные линии и радиоволны, которые имеют ограниченную пропускную способность и подвержены шуму.
Совместимость: благодаря модуляции цифровые системы могут быть совместимы с существующей аналоговой инфраструктурой.
Устойчивость к помехам: различные методы модуляции могут быть более устойчивы к различным типам помех и шумов, что улучшает качество передачи данных.
Повышение пропускной способности: использование сложных методов модуляции, таких как QAM, позволяет передавать больше данных за один цикл, что увеличивает общую пропускную способность канала связи.
Модуляция и демодуляция — это ключевые процессы, которые позволяют передавать цифровые данные через аналоговые среды, обеспечивая эффективную, надежную и высокоскоростную связь.
Электрические характеристики: определение напряжений, токов и частот, используемых для передачи данных.
Напряжение определяет разницу потенциалов между двумя точками сети. В сетях передачи данных, например, в Ethernet, используются различные уровни напряжения для кодирования цифровых данных. Низкое напряжение может быть интерпретировано как бит «0», а высокое — как бит «1».
Ток — это поток заряженных частиц через проводник. В сетях передачи данных, таких как Ethernet, ток используется для переноса информации. Изменения в токе могут интерпретироваться как изменения битовых значений данных. Потребляемый ток также определяется сопротивлением проводников и устройств, через которые проходят данные.
Частота определяет скорость, с которой данные передаются через сеть. В сетях Ethernet и других сетях передачи данных частота определяет скорость передачи данных, измеряемую в битах в секунду (бит/с). Например, Ethernet может иметь частоту 100 МГц или 1 ГГц, что определяет максимальную скорость передачи данных по сети.
Механические характеристики: определение физического соединения, разъемов и кабелей.
Физическое соединение (Physical Connection): — это способ, которым устройства в сети физически соединяются друг с другом. Физическое соединение может включать в себя различные типы кабелей, разъемов и портов. Например, в локальных сетях (LAN) устройства часто соединяются с помощью кабелей Ethernet.
Разъемы (Connectors): — это физические интерфейсы, которые позволяют подключать кабели к сетевым устройствам. Существует множество типов разъемов, каждый из которых предназначен для определенных типов кабелей и протоколов. Например:
RJ45: используется для подключения витой пары Ethernet.
LC/SC: используются в оптоволоконных сетях.
Разъемы обеспечивают надежное и стандартизированное подключение, которое гарантирует совместимость устройств.
Кабели (Cables): — это физические носители, по которым передаются данные. Тип кабеля определяет скорость передачи данных, расстояние, на которое данные могут быть переданы, и среду, в которой кабель может использоваться. Основные типы кабелей включают:
Витая пара (Twisted Pair): наиболее распространенный тип кабеля для локальных сетей. Включает неэкранированную витую пару (UTP) и экранированную витую пару (STP).
Оптоволоконный кабель (Fiber Optic Cable): используется для высокоскоростных соединений на большие расстояния. Передает данные с помощью световых импульсов.
Каждый тип кабеля имеет свои характеристики, такие как пропускная способность, устойчивость к помехам и максимальное расстояние передачи.
Разъем RJ45: используется для подключения кабелей Ethernet к сетевым устройствам, таким как маршрутизаторы, коммутаторы и сетевые карты.
Оптоволокно с разъемами LC/SC: используется как для высокоскоростных магистральных соединений и соединений на большие расстояния, так и на небольшие расстояния (как разъемы RJ).
Механические характеристики важны для обеспечения надежного и эффективного соединения между устройствами в сети. Они влияют на:
Совместимость: использование стандартизированных разъемов и кабелей гарантирует, что устройства могут быть подключены и будут работать вместе.
Производительность: тип и качество кабелей и разъемов могут влиять на скорость передачи данных и стабильность соединения.
Устойчивость к помехам: экранированные кабели и правильные разъемы могут снижать воздействие электромагнитных помех и улучшать качество связи.
Физическая защита и долговечность: надежные разъемы и кабели обеспечивают долговечность и надежность физического соединения, что особенно важно в промышленных и коммерческих сетях.
Физическая топология: определение расположения и соединения сетевых устройств.
Физическая топология сети определяет физическое расположение и соединение сетевых устройств, таких как компьютеры, маршрутизаторы, коммутаторы и кабели. Это важный аспект проектирования и управления сетью, поскольку он влияет на производительность, масштабируемость, надежность и управляемость сети.
Давайте рассмотрим основные типы физической топологии и их характеристики.
В этой топологии все устройства подключены к одному общему кабелю (шине). Передача данных осуществляется по этому кабелю, и все устройства могут получать эти данные.
Преимущества:
Простота установки и низкая стоимость.
Легкость добавления новых устройств.
Недостатки:
Ограниченная длина кабеля и количество подключаемых устройств.
Поломка кабеля приводит к выходу всей сети из строя.
Низкая производительность при большом количестве устройств.
Все устройства подключены к центральному узлу (коммутатору или концентратору). Центральный узел управляет передачей данных между устройствами.
Преимущества:
Высокая производительность, так как данные передаются через центральный узел.
Простота управления и обнаружения неисправностей.
Поломка одного устройства или кабеля не влияет на работу всей сети.
Недостатки:
Зависимость от центрального узла: если он выходит из строя, вся сеть перестает работать.
Более высокая стоимость из-за необходимости в центральном узле и большем количестве кабелей.
Устройства соединены в кольцо, и каждый узел связан с двумя соседними узлами. Данные передаются по кольцу от одного устройства к другому.
Преимущества:
Равномерное распределение нагрузки между узлами.
Отсутствие коллизий при передаче данных.
Недостатки:
Поломка одного устройства или кабеля нарушает работу всей сети.
Сложность добавления новых устройств.
В этой топологии каждое устройство подключено ко всем другим устройствам. Существует полносвязная ячеистая топология, где все устройства напрямую соединены друг с другом, и частичная ячеистая топология, где некоторые устройства соединены не напрямую.
Преимущества:
Высокая надежность: сбой одного устройства или кабеля не влияет на работу всей сети.
Высокая производительность и минимальная задержка.
Недостатки:
Высокая стоимость и сложность установки.
Сложность управления и обслуживания.
Комбинация звездной и шинной топологий. Устройства соединены в группы, которые, в свою очередь, соединены центральными узлами.
Преимущества:
Иерархическая структура упрощает управление.
Легкость масштабирования сети.
Недостатки:
Зависимость от центральных узлов.
Более сложная установка по сравнению с простой звездной топологией.
Производительность: различные топологии предлагают разные уровни производительности и могут справляться с разными объемами трафика.
Надежность: топология влияет на устойчивость сети к сбоям. Некоторые топологии более устойчивы к поломкам отдельных устройств или кабелей.
Масштабируемость: разные топологии по-разному справляются с добавлением новых устройств и расширением сети.
Управляемость: некоторые топологии проще в управлении и диагностике неисправностей.
Стоимость: стоимость установки и обслуживания сети зависит от выбранной топологии, так как разные топологии требуют разного количества кабелей и оборудования.
Физическая топология сети играет ключевую роль в проектировании, управлении и обслуживании сетевых систем, обеспечивая оптимальную производительность и надежность.
Кабели и разъемы: RJ45, оптоволоконные кабели, коаксиальные кабели.
Электрические характеристики: RS-232, V.35, 100BASE-TX, 10BASE-T.
Беспроводные стандарты: 802.11 (Wi-Fi), Bluetooth.
RS-232: стандарт для последовательного обмена данными. (это не разъем как обычно считают, DE-9 это разъем, а RS-232 это стандарт)
V.34: стандарт для модемов, который определяет методы модуляции для передачи данных по телефонным линиям со скоростью до 33.6 Кбит/с.
100BASE-TX: стандарт для передачи данных по витой паре на скорости 100 Мбит/с.
802.11: набор стандартов для беспроводных сетей.
На практике физический уровень используется для создания и поддержания физических соединений между сетевыми устройствами. Например, когда вы подключаете компьютер к маршрутизатору с помощью Ethernet-кабеля, вы взаимодействуете с физическим уровнем. Важно понимать, что любые проблемы с кабелями или разъемами на этом уровне могут приводить к сбоям в передаче данных.
Когда сетевой кабель выдергивается, это затрагивает только физический уровень сетевой модели OSI, но как это влияет на работу протоколов TCP/IP?
Физический уровень отвечает за передачу данных по физической среде, такой как медный кабель или оптоволокно. Когда сетевой кабель отключается, устройства на этом уровне теряют способность передавать сигналы. Этот уровень может распознать, что кабель выдернут, так как электрический или оптический сигнал больше не поступает.
Канальный уровень взаимодействует непосредственно с физическим и управляет доступом к среде передачи данных, обнаружением ошибок и управлением потоком. При отключении кабеля сетевой интерфейс, например, Ethernet, сигнализирует об ошибке, такой как «link down». Это событие фиксируется на этом уровне, но не обязательно передается выше.
Протоколы стека TCP/IP (такие как TCP, UDP, IP) работают на более высоких уровнях и не имеют прямого доступа к информации о физическом состоянии соединения. Они оперируют виртуальными представлениями сети, предоставляемыми нижележащими уровнями. Поэтому, когда кабель отключается, TCP/IP не узнает об этом напрямую, если информация о разрыве соединения не передается с более низких уровней.
Для того чтобы протоколы верхнего уровня, такие как TCP, могли узнать о разрыве соединения, используются специальные механизмы:
KeepAlive: после установления соединения и при включенной опции KeepAlive, TCP начинает отправлять небольшие контрольные пакеты по истечении определенного времени бездействия. Если определенное количество пакетов KeepAlive не получает ответа, TCP считает соединение недействительным и инициирует его разрыв.
Тайм-ауты: TCP пакеты имеет встроенные механизмы тайм-аутов, которые позволяют определить, что данные не были доставлены в течение определенного времени. В случае тайм-аута TCP предпринимает попытку повторной передачи данных или разрыва соединения.
Когда сетевой кабель отключается, это сначала обнаруживается на физическом и канальном уровнях сети. Однако, если информация об отключении не передается выше, протоколы TCP/IP не узнают об этом напрямую. Для решения этой проблемы в TCP предусмотрены механизмы, такие как KeepAlive и тайм-ауты, которые помогают обнаружить потерю соединения и принять соответствующие меры. Эти механизмы обеспечивают надежность и устойчивость работы сетевых приложений, даже при физических сбоях в сети.
Физический уровень модели OSI является основой для всех остальных уровней. Без надежного физического соединения остальные уровни не смогут выполнять свои функции. Понимание работы физического уровня поможет вам эффективно устранять неисправности и оптимизировать работу сетевых устройств.
В следующей статье мы рассмотрим канальный уровень (L2) и его роль в сетевом взаимодействии.
Спасибо за внимание, и до встречи в следующей статье!
Написано специально для Timeweb Cloud и читателей Пикабу. Больше интересных статей и новостей в нашем блоге на Хабре и телеграм-канале.
Хочешь стать автором (или уже состоявшийся автор) и есть, чем интересным поделиться в рамках наших блогов — пиши сюда.
Облачные сервисы Timeweb Cloud — это реферальная ссылка, которая может помочь поддержать авторские проекты.
Автор текста: georgy_zenker
Прошлая серия эпопеи с производством электросерфов, закончилась на отвратительном слове — «импортозамещение».
Раз уж решили — так было бы логично делать силовую установку в едином модуле: водомет + мотор + контроллер. Меньший объем гораздо проще герметизировать, да и ремонтопригодность выше: поменял спрямляющий аппарат, импеллер или модуль целиком и доска снова в работе.
Конструктивизм наше все и первые модули были опутаны трубками охлаждения и проводами, как кот запутавшийся в клубке ниток.
Сделать по другому не очень получалось, поскольку и мотор и контроллер имели проточные контуры охлаждения.
Прошлые годы опыта чему-то нас все таки научили, и доверившись аксиоме «не сошлось в экселе — в жизни точно не сойдется», было принято решение не продолжать разработку своего контроллера, ибо единичные партии чего-либо сложнее палки никогда не будет дешевле любого серийного варианта.
По итогу перебора разных дендрофекальных изделий на основе VESC была найдена достойная замена: проприетарный влагозащищенный контроллер (IP 67), полностью подходящий по параметрам.
От идеи возведения вокруг него рубашки охлаждения отказались достаточно быстро, т. к. получалось масло масляное, и гораздо логичнее было бы обеспечить прямое охлаждение забортной водой.
Примерно в это же время приехал долгожданный мотор 4-й итерации, сделанный в РФ. По размерам он был немного больше своего младшего брата, и засунуть в доску его удалось не сразу.
Тестов этого мотора лично я ждал почти 1,5 года и по итогу все вернулось на круги своя: при общем весе доски и райдера больше 130 кг — медленно, но верно шел нагрев и в режиме полного газа, через 20 минут мотор сваливался в перегрев.
Сказать что это было фиаско — ничего не сказать: почти 5 лет и 4 попытки построить действительно подходящий двигатель пошли в известном направлении (я уже молчу про деньги).
Но был и план Б — взять погружную версию китайского мотора (который использовали еще на старте эпопеи в 2019 и который перегревался за 5-7 мин (в исполнении с рубашкой охлаждения)), т. е. в итоге должна была получится концепция исключительно на пассивном охлаждении.
Я сам в эту концепцию не очень верил, так как на мой взгляд, что подавать воду через штуцера, что просто утопить половину мотора — равнозначно. О как же я ошибался.
Для тестирования модулей изготовили принципиально другой корпус, с упором под прокаты и гораздо большим водоизмещением.
На первых тестах не удалось нагреть мотор выше 33 градусов (при температуре воды +15).
Когда спустя 2 недели ситуация не изменилась, и даже при весе райдера в 90 кг — температура не росла, у меня было двоякое ощущение: вроде и успех, но ощущения закопанных 5 лет в тупиковую технологию меня вгоняла в ощущения собственной глупости и однобокости мышления. Вы можете сказать: «настоящий инженер бы все посчитал предварительно». Этим я и занимался при проектировании 4-х итераций нашего мотора с около нулевой эффективностью в итоге, а тут несколько тестов все расставил на свои места.
Коли концепция рабочая, надо было финализировать модуль и придать ему законченный и минималистичный вид.
Три раза перекрестившись — еще и подняли ток буста (8 сек) до 300А: не знаю, помог ритуал или погружная конструкция, но все элементы такую нагрузку выдержали, и условный пинок с места получилось обеспечить. Да, это все равно отличается от подрыва бензиновой доски, но уже сильно лучше предыдущей конфигурации
В версии со 108 мм водометом (сейчас 94 мм), надеюсь, получится достигнуть подобного ускорения (пока в разработке).
Да-да, ребра можно и нужно спилить, но делать мы это конечно же не будем, т. к. в соленой воде алюминий без анода гниет очень быстро. В следующие итерациях контроллер будет в исполнении без ребер охлаждения.
Коммерческих надежд на модуль несколько больше, чем на доску, ибо его можно вставить хоть в бревно и оно выйдет на глиссер.
Доски делать не бросаем, но теперь упор больше под прокат, т. к. B2B сектор понятнее и предсказуемее.
История продолжается…
Написано специально для Timeweb Cloud и читателей Пикабу. Больше интересных статей и новостей в нашем блоге на Хабре и телеграм-канале.
Хочешь стать автором (или уже состоявшийся автор) и есть, чем интересным поделиться в рамках наших блогов — пиши сюда.
Облачные сервисы Timeweb Cloud — это реферальная ссылка, которая может помочь поддержать авторские проекты.
Автор текста: akibkalo
Сегодня я начинаю небольшой цикл статей, посвященных операционной системе Microsoft — Azure Stack HCI. Да, именно посвященных ОС, а не решениям Azure, рассматривать я буду именно серверную ОС на базе ядра Windows Server с названием издания Azure Stack HCI, которая вот уже пять лет как ежегодно выходит по программе ежегодного (не долгосрочного) цикла выхода серверных ОС. На данный момент мой план таков:
1) В первой (этой) статье я опишу своё видение того, что такое Azure Stack HCI, чем он отличается от ОС Windows Server Datacenter Azure Edition (Core), что отличает Azure Stack HCI от сервисов Azure Stack, самое главное, для чего вам такая странная ОС в вашем датацентре;
2) Во второй статье я буду рассказывать о том, что такое Hot Patching, — процедура установки обновлений безопасности Microsoft без перезагрузки, какие требования к ОС имеются, — и самое главное, как обойти обязательность наличия подписки Azure, то есть как пользоваться Hot Patching в вашем датацентре без каких-либо Azure Benefits, как создавать виртуальные машины на базе ОС Windows Server и любых её ролей так, чтобы обновления ОС внутри ВМ не требовали их перезагрузки (как вы прекрасно понимаете, обновление хост ОС не требует перезагрузки ВМ в виду живой миграции между узлами кластера). Это весомый аргумент в пользу виртуализации Windows сервисов именно на базе Hyper-V;
3) В третьей статье я расскажу о том, как превратить ОС AzureStackHCI, которая поставляется исключительно в режиме Server Core в ОС с полным рабочим столом, чтобы у вас была возможность полноценно её администрировать. Причем сделать это таким образом, чтобы на ОС все так же продолжали приходить обновления с Windows Update.
Если в комментариях будут предложения дополнительно добавить темы, я открыт к таким предложениям.
Итак, что же такое Azure Stack HCI в 2024 году.
На Хабре есть неплохие статьи об Azure Stack (статья Azure Stack: Немного теории / Хабр (habr.com) от 2017 года) и Azure Stack HCI (статья Что такое Azure Stack HCI и как это работает / Хабр (habr.com) от 2020 года), которые в целом дают понимание о том, что такое службы Azure, в том числе и on-premises. За несколько лет, прошедших с тех публикаций основное отличие заключается в том, что AzureStackHCI теперь это издание ОС на Windows Server, выходящее раз в год, предназначенное для создания гиперконвергентной инфраструктуры на вашем оборудовании. Я очень рекомендую для начала тем, кто совсем не в курсе решения Azure Stack HCI прочитать вышеупомянутую статью корпоративного блога Microsoft, ибо я вообще не буду рассматривать ни аппаратные требования, ни процессы создания кластеров и управления имя, я буду говорить сегодня чисто об операционной системе.
Microsoft говорит, что "AzureStackHCI, — это решение гиперконвергентной инфраструктуры (HCI), в котором размещаются виртуальные машины Windows и Linux или контейнерные рабочие нагрузки и их хранилище. Это гибридный продукт, который подключает локальную систему к Azure для облачных служб, мониторинга и управления." Как и любое другое издание Windows Server, вы можете загрузить Azure Stack HCI с сайта Microsoft. Обращу внимание на то, что сейчас там предлагается загрузить версию 23H2, тогда как уже существует и 24H2, доступная на UUP, о которой я и буду вести речь в этом цикле статей. Версия 24H2 основана на базе ядра germanium, того же, что используется в Windows Server 2025 и Windows 11 24H2. Соответственно, и компоненты и обновления у данных ОС общие.
Обычно, отпугивающим фактором для начинающих администраторов является то, что Azure Stack HCI это всегда Server Core. То есть нет кнопки Пуск, Параметров и иже, нет ни MMC ни панели управления, при старте доступен sconfig, дальнейшее управление локально из командной строки или PowerShell или удаленное средствами Azure Arc и Windows Admin Center:
В Azure Stack HCI 24H2 входят лишь те роли, которые требуются для создания гиперконвергентной инфраструктуры, в первую очередь, Hyper-V и файловый сервер (включая Storage Spaces Direct), а также другие компоненты, такие как поддержка высокой доступности средствами Failover Clustering.
Как вы видите, список ролей невелик (точнее список велик, но это в основном Features). Основных ролей, имеющихся в Server Datacenter Core (обычном или Azure Edition) - таких как ADDS, ADCS, ADFS, DHCP, DNS и далее в нем нет. Но в них нет нужды на узле виртуализации, тем более Core. Вы установите полные версии Windows Server в виртуальных машинах, особенно если будет работать Hot Patching и обновления без перезагрузок.
Azure Stack HCI как ОС купить нельзя, она не лицензируется по узлам или процессорам, в отличии от традиционных решений, предполагается, что вы являетесь подписчиком Azure и будете управлять кластером при помощи Azure Arc или других средств, таким образом монетизируя затраты Microsoft. Раз ОС не лицензируется, то и активации, как класса в ней нет, ничего с ней делать не требуется:
Заводите ОС в домен, подключайтесь удалёнными средствами управления, создавайте кластер, хранилище Storage Spaces Direct, виртуальные машины Hyper-V и используйте без покупки серверных лицензий вообще, если внутри гостевых виртуальных машин у вас ОС Linux или клиентские ОС (например ферма Windows Virtual Desktop). Для лицензирования серверных ОС Microsoft внутри виртуальной среды следует как и ранее покупать лицензии Datacenter по ядрам процессоров ваших узлов виртуализации или устанавливать издания с подпиской (доступно только для Azure Stack HCI). Если потребуется, вы можете использовать встроенную в Hyper-V возможность Automatic Virtual Machine Activation (AVMA) и с AzureStack, для этого потребуется Windows Admin Center и ручная привязка ключей Windows Server Datacenter к узлам Azure Stack HCI. Если ваш AVMA ключ имеет Software Assurance или Subscription, то AVMA сможет активировать и виртуальные машины с Windows Server Azure Edition (те самые, в которых работает Hot Patching).
Не путайте Azure Stack HCI (издание ОС Windows Server) с решением Azure Stack (связка ОС Windows Server, OEM железа от какого-либо вендора-партнера и сервисов). Azure Stack это готовое решение, не всегда на базе Azure Stack HCI (чаще на базе Windows Server Datacenter), которое продаётся предустановленным в виде стойки с серверами, хранилищем, коммутаторами. Azure Stack идёт уже настроенным и готовым, - дорого, менее гибко, сложно обновлять. Azure Stack
Отдельно замечу, для виртуальных машин, работающих в Azure Stack HCI бесплатна доставка расширенных обновлений (ESU). То есть, если у вас в виртуальной машине установлен Windows Server 2012/R2 и SQL Server 2012, вы будете получать Extended Security Updates, которых не получат ОС, установленные на железе или любой другой виртуализации (в том числе и Hyper-V на базе Windows Server Datacenter).
Следующей статьей я расскажу о самой интересной возможности Azure Stack HCI — Hot Patching и поделюсь информацией, как установить данный функционал без покупки подписок Azure (в нашей стране их ведь купить невозможно? :)
А после поговорим о том, как довести до ума Azure Stack HCI, добавив ей полноценный рабочий стол, чтобы было комфортно администрировать, — таким образом можно будет использовать Azure Stack HCI как решение для виртуализации в небольшом офисе, где нет других серверов, нет подписок Azure и знатоков управления Server Core, с возможностью использовать Hot Patching.
Подписывайтесь, ставьте лайк, пишите комментарии, чего отдельно хотели бы увидеть в следующих статьях по Azure Stack и другим поделкам Microsoft!
Написано специально для Timeweb Cloud и читателей Пикабу. Больше интересных статей и новостей в нашем блоге на Хабре и телеграм-канале.
Хочешь стать автором (или уже состоявшийся автор) и есть, чем интересным поделиться в рамках наших блогов — пиши сюда.
Облачные сервисы Timeweb Cloud — это реферальная ссылка, которая может помочь поддержать авторские проекты.
Автор текста: ThePolymer
Однажды компания Kodak украла у Polaroid патенты. Это случилось в 1976 году, когда Kodak представила свою первую мгновенную камеру. Конечно, у конфликта есть предыстория, но Kodak хотели обставить ситуацию не как воровство, а как здоровую конкуренцию. Обе компании – лидеры рынка, а их конкуренция и последующий суд превратились в крупнейший скандал. Суд длился 14 лет!
В этой публикации мы расскажем о конфликте двух корпораций, историю разработки моментальной фотографии, сравним цены и модели фотоаппаратов, а также вы узнаете об удивительной роли кассет VHS и дискет на 3,5 дюйма в этой и без того запутанной истории. За то время, пока шел суд между Kodak и Polaroid, мир успел измениться, и результаты суда получились совершенно неожиданные!
Компания Kodak создала рынок фотографии, когда Джордж Истман в конце XIX-начале XX веков внедрил гибкую фотопленку – именно он придумал делать фотоаппараты не из дерева и латуни, а из картона и кожзама. Фотоаппараты Kodak стали доступны простому человеку за счет снижения цены камеры. В 1900 году самая примитивная камера в мире Kodak Brownie I стоила 1 доллар (около 40 долларов в современных деньгах). В конце XIX века большой фотоаппарат стоил в тысячи раз дороже. Существовавшая в те времена бизнес-модель Kodak сохранилась на весь XX век: фотоаппараты продавались в убыток, чтобы стимулировать продажу пленки. Кстати, пленка Kodak, в отличие от камер, вполне подходит профессиональным фотографам. Другие источники доходов мы тут рассматривать не будем.
Компания создала рынок пленки. Все думают, что фотокамера – это главный товар Kodak, но, на самом деле, камеры продавались в убыток, чтобы продавать больше пленки. Тем не менее, в среднем классе простых и дешевых камер Kodak делали лучшую фототехнику.
Главное, что надо знать о компании Kodak, – это огромная международная корпорация: около 150 тысяч сотрудников и десятки заводов по всему миру. Она была главным мировым поставщиком в области фототехники (исключая только секторы профессиональных и узкоспециализированных фототоваров). Кроме того, компания Kodak производила кинопленку для Голливуда, разные (простые, в основном) кинокамеры, проекторы и даже товары общего потребления. Именно Kodak приучила американцев, что лучший подарок на Рождество – это фотоаппарат.
Компания Polaroid появилась в 1937 году и первые 43 года работала под управлением основателя Эдвина Лэнда. Этот энергичный изобретатель задал компании импульс с технологией поляризации, а в 1947 году он представил миру фотоаппарат, способный сделать фотографию за 1 минуту. Технология работала не без нареканий, но широкую публику поразила в самое сердце. Продажи были успешными. В 1963 году появилась цветная мгновенная фотография. Эдвин Лэнд стал звездой в Америке, а компания Polaroid обрела настоящий успех и приносила выручку в 500 миллионов в год.
Эдвин Лэнд, основатель компании Polaroid, любил проводить презентации на сцене, загадочно зазывая журналистов. Стив Джобс делал также – и теперь вы знаете, у кого он подсмотрел подачу. Эдвин Лэнд был настоящим визионером. Этот человек еще в 1960-х предсказал смартфон!
С 1947 по 1975 года компания прошла эволюцию в технологиях, поколениях камер и покорении умов. Первые два поколения продавались хорошо, на уровне необычного гаджета. Kodak не видели угрозы, ведь тогдашний успех Polaroid – это доля рынка на уровне статистической погрешности (0,5-1,5%). Но когда покупатели привыкли к технологии и вышло третье поколение камер, Polaroid стала международной, узнаваемой наравне с Kodak, а Эдвина знал весь мир наравне с Элвисом, рост Polaroid испугал Kodak.
Неизвестно, когда в Kodak появилась идея влезть на рынок мгновенной фотографии. Да и причины тоже не до конца понятны. Вероятно, они испугались роста сектора мгновенной фотографии и роста выручки Polaroid. Бизнес-модель Polaroid была идентична опыту и модели Kodak: создавать и продавать фотокамеры с минимальной наценкой, а прибыль получать на расходных материалах.
Можно ли было представить в 1970-м году, что весь рынок фотографии перейдет на технологию моментальной фотографии? Это такой же сложный вопрос, как и вопросы вроде – кто в 1980-м году в IBM мог подумать, что микрокомпьютеры могут быть популярны и станут важнее мейнфреймов? Кто мог предсказать, что цифровая фотография уничтожит рынок аналоговой в 1990-м году? А кто в 2005-м мог бы предположить, что смартфоны отберут долю рынка у цифровых фотоаппаратов? Кто в 2010-м верил, что электрические автомобили займут крупную долю рынка в развитых странах через 20 лет?
Обратите внимание на эту иллюстрацию. Повезло найти качественный скан рекламы. Дело в том, что Kodak еще в начале XX века придумали публиковать в рекламе комиксы о простоте использования камер. Polaroid пошли похожим путем в 1950-х. Без комикса или чтения инструкции тут, действительно, не разобраться.
В 1950-60-х Kodak производил для Polaroid запчасти и химию. Очевидно, Kodak видели всю технологию, знали подробности механики и, без сомнений, могли все скопировать. Предвидя такие риски, Эдвин Лэнд хорошо подготовился и получил патенты на все компоненты и идеи, заложенные в Polaroid. Эдвин, кстати, войдет в мировую историю как один из самых плодовитых на патенты изобретателей. Знаете, чем он занимался в 1945-1947 годах? Он старательно и последовательно патентовал все свои разработки, так как потом пришел с ними в тот же Kodak с предложением купить весь проект за огромные (неизвестные нам сегодня) деньги. И тогда Kodak ему отказали.
Модель Polaroid 104 одна из самых массовых в 1970-х и… сегодня! Да, фанаты марки любят эту серию раскладных (термин folding еще с 1900 года живет) камер.
Итак, в компании Kodak решили, что пора бы сделать и собственную мгновенную камеру. Полагаем, что такое решение приняли в середине 1960-х. Несколько лет ушло на разработку в условиях, конечно, полной секретности. Были отлажены все процессы, и Kodak уже готовила продукт для выхода на рынок. И вдруг как гром среди ясного неба в 1972 году компания Polaroid выпустила новый тип расходных материалов, что заставило Kodak отложить старт и начать копировать уже обновленную технологию.
Kodak Instamatic 104 – одна из самых массовых камер 1960-1970-х. Простая, компактная, потом такие в русскоязычном мире называли мыльницы, а в англоговорящем – point-and-shoot camera. Знаете, чем еще примечательна серия Instamatic? Именно в ее честь названо приложение Instagram.
Выход камеры Polaroid SX-70 важен по двум причинам. Во-первых, она обрела культовый статус из-за невероятного дизайна – она раскладывалась, что поражает до сих пор. Во-вторых, в SX-70 использовался новый тип пленки. Об этом чуть ниже.
Эта модель стала настоящим прорывом. Удачная конструкция, отличные характеристики, рекордные продажи. Любой фанат марки начинает коллекцию с этих 4 моделей: Polaroid 95, Polaroid (складная) 200-420, Polaroid SX-70 и Polaroid Spectra.
В истории Polaroid было несколько периодов революционного роста. Самый яркий (1963-1975) связан с тремя новинками: выход цветной фотографии, появление кассет с кадрами (тип) и легендарная камера Polaroid SX-70.
Если посмотреть количество проданных камер, долю рынка и выручку, то Polaroid показывал очень хорошую динамику между 1950 и 1980 годами. Каждый год – плюс 10-20% к выручке, акции тоже росли, но это не столь важно. Важно, что каждая следующая камера приближала Polaroid к Kodak по объемам выручке и доле рынка. Когда в 1965 году вышла камера Polaroid Swinger за 20 долларов, Polaroid стал еще на на шаг ближе к цели. Такие камеры, хоть и выглядели нелепо, (см. рекламный ролик Polaroid Swinger), но стоили очень дешево и продавались отлично.
Сначала мгновенная техника Polaroid занимала 1-2% фоторынка в США. В начале 1960-х уже до 5-7%. Kodak забеспокоился. А вот после трех прорывных событий и бурного периода роста Polaroid, Kodak уже начали нервничать: 1963-1975 годы – выход цветной мгновенной фотографии сильно простимулировал продажи и котировки Polaroid. Тогда же вышли кассеты для снимков и легендарная SX-70. Кроме того, техника Polaroid получила распространение в госструктурах. Оказалось, что при изготовлении пропусков, удостоверений и полицейских магшотов мгновенная фотография – разумный выбор. В итоге Polaroid даже выпустили специальную камеру для документов.
Крупный американский художник Энди Уорхол был большим фанатом марки Polaroid. Он не только везде таскал их камеру с собой, он как бы был неофициальным лицом марки. У Kodak не было ничего похожего: ни амбассадора, ни лица, ни легенды. Точнее лица в рекламе Kodak менялись часто, основатель Kodak, Джордж Истман, остался в истории.
Так, к 1972 году доля Polaroid на рынке США в целом достигала уже 17-20%. Выручка компании в 1960-х превышала 500 миллионов долларов в год, затем рост чуть замедлился и резко ускорился. К 1976 году выручка уже составляла 1 миллиард и неумолимо приближалась к отметке в полтора миллиарда. Так Kodak и осознали, что Polaroid – это уже не средняя фирма с необычным «продуктом», а компания, которая чисто теоретически может вообще поставить крест на старомодной фотопленке.
Но в технологии Polaroid существовало и слабое место – это расходные материалы. Надо уточнить, что было 3 этапа и, соответственно, 3 подхода к передаче изображения на негатив-позитив. Они все по-разному работали, их объединяло только то, что через 30-120 секунд у вас в руках была полностью готовая фотография.
Первый тип материала продавался в рулонах. Рулон заправлялся в камеру и имел два хвоста: для химии и для бумаги. После фотографирования нужно было вытянуть один хвост, в процессе чего оба хвоста соприкасались.
ROLL
Тип 1: многослойная пленка, которая расклеивалась после ожидания, и через пару минут получалась фотография. Пример на видео – Polaroid 95.
PACK
Тип 2: пачка снимков, химии и батарейка в упаковке, которые загружались в камеру. Продаваться начал в 1963 году. После спуска затвора снимок можно было вытащить из камеры или он подавался мотором за 30-60 секунд. Это экономило время, а главное – процесс смены картриджей был гораздо проще.
INTEGRAL
Тип 3: картридж нового поколения, все то же самое (пачка снимков, химия, батарейка). Начало продаж – 1972 год. Но скорость всех этапов значительно возросла. Именно в таком виде и с характерным узнаваемым звуком камеры Polaroid вошли в 1990-е годы.
Итак, Kodak выпустили моментальную фотографию – технология, фотокамеры и расходники. Рекламная кампания была беспрецедентной. Они предложили конечному потребителю фотокамеры по той же цене, что и Polaroid, но вот снимки были немного дешевле. Кроме того, у Kodak сеть продающих партнеров была куда обширнее, чем у Polaroid. Kodak могли потратить на маркетинг в 5, 10 и даже 20 раз больше денег.
Камера Kodamatic в первой версии не имела моторчика, готовый кадр надо “выжимать”, покрутив ручку (см. рекламный ролик). Обратите внимание, Kodak сделали совершенно иной тип корпуса, чтобы не было претензий по патентам в механике и оптике, поэтому у Polaroid готовый снимок почти всегда спереди, у Kodak – сзади. На фото камера ColorBurst, а кассета пленки тут только для масштаба (лучше, чем пачка сигарет).
Первая камера носила название Kodak EK4, или Kodamatic. Моторчика на ней не было, чтобы получить снимок, нужно было крутить ручку. Кстати, камеры мгновенной фотографии всегда были и остаются относительно крупными. Они весили до 5 кг, в разы крупнее обычных камер, поэтому у Polaroid и у Kodak на многие модели устанавливалась крупная рукоятка (что, кстати, было характерно и для 1920-х, когда камера со вспышкой была очень очень громоздкой). Одна из моментальных камер Kodak даже носила имя Handle.
Качество фотографий у Kodak было незначительно выше, чем у Polaroid. В общем, для Polaroid выход Kodak на рынок мгновенной фотографии стал началом конца. Можно было продавать акции и готовиться к падению. Первичная реакция рынка на выход камеры от Kodak: давайте подождем. Потребовалось 3 года, чтобы понять, что камеры от Kodak все-таки хорошо выполняют свою работу, снимки на нее качественные, а цены на расходники лучше, чем у Polaroid.
Активная реклама от Kodak в прессе. Самая яркая была, конечно, на ТВ (пример, видео).
В компании Kodak считали, что они не нарушают патенты Polaroid, так как они «разрабатывали всю химию и механизмы с нуля». Просто поставили цель – готовая фотография за 30-60 секунд. У Polaroid снимок выезжал впереди, у Kodak – сзади. Нет, это, конечно, не главное, это следствие того, что Kodak постарались сделать все не так, как у Polaroid: ориентация линз и механизмов иная, размеры, принцип и последовательность событий. Химические процессы они также изменили, как последовательность и количество слоев в фотобумаге. Kodak уверенно заявляли: у нас камеры работают не так, как у Polaroid.
Fuji занимала доминирующую позицию в Японии и копировала бизнес-модель Kodak. В 1970-х она вышла на рынок США, и началась настоящая война. С одной стороны, Kodak испытали давление и по цене, и по присутствию на рынке, с другой стороны, в 80-х им было даже выгодно, что на рынке есть конкуренты, иначе они казались бы (и являлись по факту) монополистами.
Камера Fujica ST701 вышла в 1970 году и стала одной из самых успешных камер. Благодаря качеству такие японские аппараты получили признание по всему миру, особенно в профессиональной среде.
В 1984 году прошли Олимпийские игры в Лос-Анджелесе. Kodak впервые за 50 лет отказался выступить спонсором национальной сборной (в США государство не помогает спорту, как было принято в некоторых странах, например, в СССР) и возникла забавная коллизия: японская компания Fuji финансировала американскую сборную. В общем, противостояние было жестким, до судов доходило не единожды.
Однако время от времени конкуренты находили возможность и для сотрудничества. Порой весьма необычного. Так, в конце 1970-х Fuji обратилась к Kodak за лицензией на мгновенную фотографию. Polaroid не хотели делиться, они активно проникали на рынок Японии, Европы и Азии еще с 1950-х годов. А Kodak уже получили негативный опыт в Японии, провалившись при попытке выйти на их рынок. Так что Kodak справедливо рассудили, что лучше получить союзника хотя бы на одном из фронтов.
Серия Fuji Fotorama MX800 – главная мгновенная камера от японской компании после 1984 года. И все камеры Fuji работают на технологии, которую лицензирует Kodak.
Роль Fuji была и будет уникальной. Например, в XXI веке только эта компания поймет, что химия для фото-индустрии похожа на химические технологии в косметике и смело зайдет на новый рынок. А в истории войны Polaroid и Kodak японская корпорация также сыграла необычную роль.
Успехи Fuji в сделке с Kodak можно описать так: они выпустили свою версию фотоаппарата на основе технологии и химии от Kodak. Только в Японии. Их позиции усиливались с каждым годом. Но оставалась проблема: как можно продавать что-то, имея лицензию на продукт, по которому прямо сейчас идет судебный процесс?
Помимо конкуренции на мировых рынках и суда с Kodak, внутри Polaroid к 1980 году сформировался другой кризис, который привел к отставке Эдвина Лэнда. Это было результатом трех крупных провалов подряд. Можно сказать, что Лэнд лично виноват как минимум в двух.
В конце 1960-х Polaroid ставила рекорды роста котировок акций, до 125 долларов за 1 акцию в 1969 году. Следующий рекорд был поставлен в 1980-м году: выручка достигла 1,451 миллиарда. В том же году выручка в расчете на 1 акцию – 2,6 доллара. за 40 лет Polaroid произвел 7,5 миллионов фотокамер марки Polaroid Land Camera.
А вот следующие 5 лет будут крайне тяжелыми. Продажи Kodak росли, а у Polaroid падали. С одной стороны, общественное мнение находилось на стороне Polaroid, и Kodak с выходом на рынок инста-фото выглядели как пираты. Но вместе с тем Kodak – в 50 раз крупнее Polaroid. Многие боялись покупать камеры Polaroid, справедливо предполагая, что им осталось недолго, и Kodak в итоге победит.
Polaroid в те же годы потерпели крах и с другим проектом – провалилась технология Polavision. На нее тратили все свободные деньги более 5 лет, но детище Эдвина Лэнда так и не взлетело.
Polavision стал главным провалом компании. Эдвину Лэнду (1909-1991) уже более 70 лет, очевидно, что он промахнулся (а это его проект) и стареет.
Ну и последнее. К 1980 году всем стало понятно, что Kodak выигрывают по цене и качеству фотографий. Судебный процесс шел медленно, начавшись 4 года назад, и Kodak тянули время. Как известно, крупным компаниям выгодно затягивать суды, чтобы измотать противника. Все это привело к падению выручки Polaroid в 81-85 годах на 30%.
На фоне кризиса, который стал очевиден и для сотрудников, и для прессы, генеральный директор Эдвин Лэнд покинул свой пост. Ему было 72 года, и он владел 533 патентами в сфере оптики, химии и механики.
Важный момент: Эдвин Лэнд потерял пост из-за проекта Polavision, а не из-за конкуренции с Kodak. Конечно, он ошибся с этой технологией, однако он был визионером, сформировавшим Стива Джобса и предсказавшим появление смартфонов.
В 1986 году суд постановил остановить продажу товаров по сектору мгновенной фотографии марки Kodak. Kodak нарушил как минимум часть патентов, Kodak 10 лет получал выручку и прибыль незаконно.
Судебный процесс шел с 1976 года. Сторона истца – Polaroid – декларировала нарушение 12 патентов и заявила упущенную прибыль, ущерб репутации и суммарные требования на 12 миллиардов долларов. Сумма, где есть число 12 и 9 нулей – это шокирующие претензии. Мировой рекорд. Как вариант, можно трактовать так: претензия на 1 миллиард – это мировой рекорд, а вот претензии на 12 миллиардов – это буквально сообщение “Мы хотим вашей смерти”!
Камера Kodak Handle, по легенде, получила народное название за боковую ручку. Тяжелая и крупная камера стала самой популярной моментальной камерой от Kodak.
Сразу после решения суда по всем США идет волна возмущения. Магазины в один день снимают все товары мгновенной печати от Kodak. А самый неприятный вопрос, который с этого момента будет задаваться: что же делать тем, кто купил камеру Кодак, если теперь нельзя купить расходные материалы?
Эдвин Лэнд прожил 81 год, создал 533 патента (что делает его одним из самых плодовитых изобретателей в истории). Он умер в 1991 году.
Прошло еще пять лет. Наконец вышло окончательное решение суда: компания Kodak должна выплатить 909 000 000 долларов за нарушение 2 патентов. А также 16 миллионов долларов штрафа, проценты за период суда (скрытая плата за затягивание процесса). Все камеры Kodak могли остаться у покупателей или по соглашению выкупались компанией Kodak.
В 1990-х главной массовой и довольно успешной камерой стала Polaroid Spectra и Polaroid серии 600, они определили то, как воспринималась марка. Кстати, камеры Polaroid серии 600 производилась по лицензии в СССР!
Сумма выплат в $ 925 000 000 – это мировой рекорд. Даже рекордная выплата по суду между Apple и Samsung не дотягивает до рекорда (там было 1.049 миллионов, надо делать поправку на инфляцию, это +30-40% к 925 млн).
Акции и валовая выручка обеих компаний изменились по результатам суда, но не катастрофически. Polaroid с 1986 года вышла из кризиса, тем более, в начале 1990-х они выпустили ряд новых камер. А акции Kodak упали в 1991 году приблизительно на 25%, что тоже нельзя назвать катастрофой.
Компания Fuji по логике должна была получить какие-то претензии от Polaroid, ведь они использовали некоторые патенты по соглашению с Kodak. В Polaroid знали, что смогут прижать Fuji и по соглашению провели обмен: Polaroid получили от Fuji технологии и права на продажу нескольких товарных групп в секторе магнитных носителей. Прежде всего, это видеокассеты типа VHS и дискеты 3,5 дюйма. То было крайне удачное решение для Polaroid, ведь в 1990-х дискеты и видеокассеты приносили заметную часть выручки на американском рынке.
Polaroid получили от японской компании лицензию на производство и продажу магнитных носителей: дискет и VHS кассет.
Компания Fuji успешнее всех вышла из кризиса цифровой революции. Они, в отличие от Polaroid и Kodak, позакрывали фабрики еще в середине 2000-х и куда более решительно вкладывались в новые рынки. Сегодня, спустя 25 лет совершенствования технологии, компания очень успешно продает камеры с принтером серии Fuji Instax. Более того, классические пленки и картриджи для Polaroid компания также до сих пор выпускает именно Fuji!
Суд стал самым крупным в истории противостояний крупных компаний. Формально, конечно, самый большой суд – это Apple vs Samsung, но без поправки на инфляцию.
Когда пыль рассеялась, выяснилось, что пока длились судебные распри между Polaroid и Kodak, началась цифровая революция. Мир изменился. Вместо того, чтобы искать новые рынки и технологии, развивать уже готовые идеи, они искали развитие через войну. Обе компании не сильно поумнели впоследствии и ушли в банкротство в XXI веке. Меньше всех пострадала компания Fuji, она умела договариваться, а значит, смогла найти решение в истории с авторскими правами, а в XXI веке активно диверсифицировала бизнес (например, начали косметический проект).
Также обращаю внимание на то обстоятельство, что обе компании совершили по одной очень большой ошибке, помимо неспособности увидеть цифровое будущее. В Kodak в 1982 году запустили проект Kodak Disc Film, который был красиво подан, разрекламирован и выведен на рынок. И по очевидным причинам провалился. А про проект Polavision, который был создан Эдвином Лэндом, я уже написал выше. Эти истории показывают, как крупные и, казалось бы, сильные компании способны допускать одну фатальную ошибку за другой.
Написано специально для Timeweb Cloud и читателей Пикабу. Больше интересных статей и новостей в нашем блоге на Хабре и телеграм-канале.
Хочешь стать автором (или уже состоявшийся автор) и есть, чем интересным поделиться в рамках наших блогов — пиши сюда.
Облачные сервисы Timeweb Cloud — это реферальная ссылка, которая может помочь поддержать авторские проекты.
Привет, Пикабу!
Мы хотели научиться создавать сервисы от момента возникновения идеи и до этапа эксплуатации, попутно освоив новые технологии.
В итоге получился экспериментальный проект «ХрюХрюКар» — сервис для борьбы с неправильной парковкой, работающий под лозунгом «Хорошие ребята говорят 'Bla-Bla' и не ставят машину на зелёной зоне».
В этой статье мы расскажем, как выбирали проект, на решение каких задач нацелен «ХрюХрюКар», какие технологии мы использовали, какие трудности возникали и что получилось в итоге.
Ну и поделимся всеми исходниками, конечно. Если вам не терпится посмотреть, то вот исходники, а вот что получилось.
В статье мы не будем вставлять блоки кода, который у нас есть в репозитории, а просто будем ссылаться на его редакцию на момент написания статьи. Так каждый сможет посмотреть то, что интересно именно ему, поэтому ссылок будет много. Также будет немного ссылок на публикации в ВК и Telegram, имейте это в виду, переходя по ссылкам.
И да, мы здраво воспринимаем критику и всегда готовы учиться у более опытных коллег, поэтому комментарии приветствуются, как и вопросы в Issues.
Я два года работаю в IT (Fullstack: Django, Go, Vue) и по работе мне приходилось сталкиваться с разными технологиями, но я ни разу не писал сервисы полностью, всегда уже были готовые проекты, в которых нужно было что-то дорабатывать. Также у меня есть брат, который вообще не имел опыта в IT, но хотел научиться программировать (с уклоном в Django).
Чтобы приобрести больше уверенности в вопросах создания сервисов, мы решили сделать проект с нуля. Брату хотелось понять как создавать backend на Django, работать с базами данных, а также разбираться с асинхронными задачами, ну а мне было интересно создать PWA на Vue3, научиться работать с картами, набить шишек на DevOps и в целом разработать сервис полностью.
Хотелось сделать проект, который был бы полезен городу и в то же время интересен для нас.
С выбором направления проблем не возникло: несколько лет назад я участвовал в работе административной комиссии и проблема неправильной парковки меня давно волновала. Были попытки внутренней автоматизации процесса, но они не увенчались успехом из-за полного отсутствия финансирования, нехватки времени и опыта в IT.
В то время все закончилось на том, что мы фотографировали нарушения на OpenCamera, после чего я загружал снимки в QGIS и скриптом извлекал данные из EXIF-тегов, осуществлял обратное геокодирование, заполняя слой. Оставалось разобраться с распознаванием автомобильных номеров и разработать функционал формирования документов (запросов/протоколов/писем), но в связи со сменой места работы, работа над проектом была остановлена.
В июле 2022 года, в рамках эксперимента, мне удалось наладить карту нарушений, но работала она очень плохо, да и выглядела ужасно:
В августе 2023 года я уже год как был занят в коммерческой разработке и понял что самое время осуществить третий подход, но уже с братом. На этом этапе мы выступали в роли граждан, полномочия которых ограничены отправкой заявления в уполномоченный орган, но даже эта задача оказалась не такой простой, как кажется.
Чтобы привлечь нарушителя к ответственности, вам необходимо:
Зафиксировать факт нарушения, время и место его совершения;
Понять кто уполномочен принимать заявления по конкретному типу нарушений на данной территории;
Составить заявление с учетом всех юридических тонкостей;
Отправить заявление в уполномоченный орган и дождаться ответа.
Вроде бы для гражданина все просто, но на практике все оказалось сложнее. Многие считают что все нарушения правил парковки относятся к полномочиям МВД (ГИБДД/ГАИ), но на самом деле это не так.
Нарушения, связанные с размещением автомобиля на территории, занятой зелеными насаждениями или на территории детских/спортивных площадок, рассматриваются в основном административными комиссиями, созданными в муниципалитетах, в рамках возложенных на них полномочий.
Кто-то из таких комиссий принимает заявления по электронной почте, у кого-то работает СЭД и есть форма для обращений на сайте, кто-то использует ПОС Госуслуг, ну а некоторые поддерживают сразу несколько способов обращения, либо вовсе принимают заявления только на бумаге...
Обращение в МВД (ГИБДД/ГАИ) — это вообще отдельная история. При разработке их формы обращения, программисты сделали все для того, чтобы граждане вообще не обращались к ним. Например, в форме обращения, «для борьбы со спамом», отключена возможность использования буфера обмена, а максимальный размер вложений в 30Мб является по сути запретом на отправку видео.
Все это, по факту, от спама защищает чуть больше чем никак, но чинит серьезные препятствия для простых граждан: если вы собираетесь обратиться в МВД, то вам, как правило, текст заявления готовит юрист. В результате, с учетом запрета на использование буфера обмена, вам приходится вручную весь текст набирать в форме.
При отправке обращений через ПОС Госуслуг есть также решения «для борьбы со спамом», о чем напишем чуть ниже.
Ко всему перечисленному добавляется банальный страх деанонимизации. Ведь для отправки заявления, вам нужно указать свои персональные данные, а это значит, что нарушитель, на этапе административного производства, узнает автора обращения и есть риск преследования.
Мы решили создать сервис, который позволит горожанам «в один клик» фиксировать факт правонарушения, а все остальные аспекты взять на себя.
В результате было интересно проанализировать насколько горожане готовы участвовать в жизни города, а также попытаться подискутировать с нарушителями в соцсетях и поработать с их возражениями.
В большинстве регионов России проблема неправильной парковки является одной из самых актуальных. Дворы и тротуары забиты личными автомобилями, а водители, нарушающие правила, придумывают себе массу оправданий, которые по сути являются отговорками:
В городе Балаково, по состоянию на 2024 год ориентировочное количество автомобилей составляет 70000 единиц. Сейчас нет возможности точно посчитать сколько из них хранятся в нарушение правил во дворах на зеленых зонах и тротуарах, но по моим наблюдениям это не менее 10% от общего количества.
Очень много автомобилей стоят неделями и месяцами в дворах без движения, что по сути превращает наши дворы в гараж. Большинство некогда зелёных зон превратились в площадки с открытым грунтом, что является одним из главных источников пыли.
В чем причины? Я думаю здесь подействовал целый комплекс факторов. В свое время власти отпустили ситуацию и автомобили постепенно переместились из гаражей и со стоянок во дворы, что превратилось в привычку. Сейчас автомобилисты уже в корне не согласны с тем, что личные авто во дворах сложившейся застройки хранить не получится.
Также мы часто слышим про отсутствие мест на стоянках. Мы решили разобраться с этим доводом и получили контакты представителей всех 30-и стоянок в г. Балаково и начали работу над картой стоянок, работающей на базе ХХК.
На данный момент мы обзвонили не все стоянки, но результат уже достоин внимания: из 17 стоянок по которым мы уже получили данные, только на одной стоянке нет мест, а на остальных — 40-60% свободно! С гаражами ситуация примерно такая же: по данным председателей кооперативов, 30-40% гаражей в городе — брошены и практически не используются.
Причины, которые нам видятся основными:
во дворе ставить «выгодней» (от предупреждения до 5000 руб. штрафа раз в 1-2 года против 1200-1600 рублей в месяц за стоянку);
до стоянки или гаража нужно ходить, а «мы привыкли от двери до двери на авто, это же удобно, 21-й век!»;
низкий шанс получения наказания: за 2023 год, согласно отчетам, на весь город ~300 админ. протоколов (и это не только по парковке);
нет общественного порицания: люди либо считают это нормой, либо просто молчат;
нехватка кадров в муниципалитете, чтобы фиксировать большое количество нарушений по всему городу. В Балаково это 27 человек, уполномоченных составлять протоколы (помимо основных обязанностей) на тысячи нарушений;
отсутствие полноценной информационной работы. Зачастую власти не способны напрямую говорить горькую правду жителям.
В рамках проекта «ХрюХрюКар» мы постарались охватить все описанные выше проблемы.
Посмотреть 12 примеров того, с чем борется ХХК можно ниже:
В десяти метрах левее полупустая стоянка. Ворота за авто — вход в самый посещаемый парк «Энергетик».
Также у входа в парк «Энергетик». На заднем плане «карман», а правее за кадром — полупустая стоянка.
Карта нарушений:
При открытии приложения загружается публичная карта нарушений. На карте доступны все нарушения, прошедшие процедуру модерации, то есть те, по которым направлены заявления.
Также на карте есть слой с автомобильными стоянками. Зеленым цветом обозначены стоянки, на которых есть места, а синим — те, куда мы еще не позвонили. Красным цветом отображена стоянка, на которой нет мест. По стоянкам также можно кликать, чтобы посмотреть подробные сведения.
Фиксация нарушений:
После авторизации, если вы находитесь на территории, за которой закреплены полномочия по какому-либо типу нарушений, то приложение запустит камеру. В компоненте камеры можно выбрать тип нарушения и сделать снимок.
После отправки снимка, сервер производит распознавание номеров и обратное геокодирование. Вы можете протестировать этот функционал приложения, поставив фиктивное местоположение на своем устройстве где-нибудь на территории города Балаково Саратовской области. Только не забудьте, пожалуйста, сразу после распознавания номеров, удалить снимок, нажав на красную кнопку.
Модерация и отправка заявлений:
Пользователю с правами модератора (членство в группе Moderator), а также суперюзеру доступна консоль модерации. Модераторы не получают в очередь модерации фотографии, авторами которых они являются. Суперюзеры — могут модерировать любые материалы.
Модерацию мы сделали в виде степпера, чтобы акцентировать внимание на конкретном в текущем моменте вопросе. Если при распознавании номеров на фотографии обнаружены сразу несколько номеров, то для них создаются отдельные записи в таблице автомобильных номеров и нарушений.
Если отклонить фотографию, то отклоняются все связанные с ней автомобильные номера и, соответственно, нарушения. Также модератор может подтвердить фото (в т.ч. адрес с геолокацией), а затем отклонить часть автомобильных номеров, а часть подтвердить, ну или подтвердить все.
В процессе модерации можно вносить правки в адрес, местоположение снимка, автомобильный номер и тип нарушения. Править ранее подтвержденные данные не получится.
Для удобства модератора, в консоли мы связали карту с Google Street View, чтобы было проще геолоцировать фото.
Если с модератором связан заявитель, то у него доступен последний шаг степпера — генерация и отправка заявления.
Если такой связи нет, то все завершается на шаге подтверждения типа нарушения. В таких случаях, модераторы, с которыми связаны заявители, будут получать уже проверенные материалы и сразу переходить на этап генерации заявления с их данными и подтверждать (отправлять) его или отклонять.
Заявления генерируются в фоне в отдельной celery-task с использованием унифицированного шаблона, либо отдельных шаблонов, которые можно закрепить за полномочиями, используя админ-панель Django.
Рендеринг заявлений производится с использованием встроенного в Django шаблонизатора.
По-хорошему, надо немного подправить код и использовать Jinja2, чтобы рендерить заявления в изолированной песочнице, но пока это не сильно актуально, т.к. создание шаблонов и заполнение данных о заявителях, полномочиях и типах нарушений ведется собственноручно, через админ-панель Django.
Точное время совершения нарушения видят только адресаты, в приложении мы отдаем пользователям и модераторам только дату.
Панорамы особенно хорошо прикладывать к нарушениям, совершенным зимой. Мы в консоли модератора предусмотрели функцию для подгрузки панорам.
После подтверждения заявления, производится его отправка в уполномоченный орган, все также в фоновой задаче celery.
По состоянию на 05/01/2024 у нас реализована автоматическая отправка только по электронной почте, что покрывает ~90% всех нарушений, которые нам присылают через ХрюХрюКар. Отправка в ГИБДД ведется почти в ручном режиме.
У нас есть простейший скрипт на JS, в который мы подставляем текст заявления из панели администратора Django и, перейдя на форму для подачи обращений уполномоченного органа, выполняем этот код в консоли браузера, чтобы заполнить все поля формы. Далее остается прикрепить файл заявления, подтвердить почту и отправить заявление.
Также мы пробовали осуществлять отправку заявлений через ПОС Госуслуг и нас удивили их методы по «борьбе со спамом». Разработчик из непонятных соображений также запретил использование буфера обмена для пользователя и установил следующие ограничения на количество обращений, направляемых через ПОС: не более одного обращения в час и не более двух в сутки.
Данные решения нам показались странными, учитывая тот факт, что для подачи обращения необходимо авторизоваться через аккаунт госуслуг.
С учетом того, что ПОС Госуслуг реализован с использованием реактивных технологий, просто так заполнить форму не получится, ведь необходимо чтобы хранилище пришло к определенному состоянию. В рамках экспериментов мы пришли к такому коду, который на данный момент выполняет свою скромную функцию.
На данном этапе мы поняли, что заполнять формы мы тоже сможем, но для этого необходимо разработать расширение для браузера, которое будет авторизоваться в ХХК, получать по очереди заявления, открывать необходимые формы и заполнять их.
Почему именно расширение?
Чисто технически, реализовать отправку заявлений напрямую с сервера ХХК, используя эндпоинты уполномоченных органов возможно. Но нам показалось это неправильным с юридической точки зрения. Заявитель все же должен взаимодействовать с формой напрямую, через фронтэнд уполномоченных органов, а мы только можем помочь в её заполнении.
За 4,5 месяца мы направили 742 заявления, 28 материалов находится на модерации. Сейчас мы получаем в среднем по 10-20 материалов в день и стараемся около 20-и заявлений в день направлять.
Примерно 90% материалов — нарушения, выражающиеся в размещении автомобиля на зелёной зоне (направляются в администрацию БМР), около 9% — стоянка на тротуаре в нарушение ПДД (полномочия отдела ГИБДД МУ МВД «Балаковское»), 1% делят стоянка на месте для инвалидов, автобусных остановках и пешеходных переходах.
За это время на сайте авторизовалось 277 пользователей, из которых:
62 присылали одно и более нарушений, в том числе;
17 присылали более десяти нарушений, в том числе;
9 присылали более двадцати нарушений, в том числе;
6 присылали более пятидесяти нарушений, в том числе;
4 присылали более ста нарушений.
Следует отметить, что мы неоднократно просили пользователей вкладываться в качество, а не в количество материалов, исходя из ограничений, которые накладываются нюансами бюрократических процедур в рамках административных производств.
На примере некоторых пользователей мы поняли что один человек может зафиксировать сотню нарушений за пару часов прогулки, а мы их можем обработать за 1,5-2 часа. Но мы понимаем, что направление большого количества заявлений в уполномоченный орган по сути является DoS-атакой и вызовет отказ в обслуживании из-за банальной нехватки кадров.
За все время работы к нам зашли 5027 уникальных посетителей ~21000 раз. Основные пики посещаемости после таких вот постов (1, 2) в местной группе автомобильной направленности. Люди находят сайт в Яндексе или нашу группу в ВК и уже от туда приходят на сайт, где ищут свои машины.
Мы оперативно получаем положительные ответы от администрации и не очень оперативно — от МВД. Все ответы стараемся выкладывать в группе, но по мере появления свободного времени. Сейчас на почте ждут обработки 53 ответа от администрации и 3 от ГИБДД, это ~250-350 административных производств (администрация в одном ответе отвечает сразу на несколько наших заявлений).
Минус в том, что мы не получаем входящих номеров от администрации (да и не запрашиваем, если честно), поэтому конкретно связать каждый ответ с конкретным заявлением сейчас не представляется возможным.
Из дополнительных источников метрик следует отметить официальные публикации администрации: 1, 2, 3, 4, 5, 6.
Также нами проводится работа с органами власти всех уровней с целью внедрения в Балаково официального приложения на базе ПАК «Помощник Москвы». Это программное решение имеет статус средства, работающего в автоматическом режиме, что позволяет исключить бюрократию в виде административных производств (штрафы будут приходить через несколько дней прямиком на Госуслуги).
Процесс не быстрый, но мы будем стараться добиться такого внедрения у нас, благо куратор проекта в лице ЦОДД Москвы оказался очень адекватным и на первое же наше письмо ответил приглашением на ВКС, где нам изложили все детали и дали рекомендации для внедрения ПАК ПМ в регионах.
Более подробно о технологиях можно почитать тут.
Облачные вычисления и сервисы:
TimeWeb Cloud — для всех вычислений (сервер БД, сервер бэкенда, сервер фронтенда, сервер почты).
Yandex.Cloud — S3-хранилище для фотографий, заявлений и иллюстраций к типам нарушений.
Google Street View API — для просмотра точного местоположения фотографии на панорамах при модерации.
OSM — для обратного геокодирования.
Деплоим все это скриптами (1, 2, 3). Хотелось бы прикрутить Kubernetes и GitLab CI/CD, но пока не хватает времени и опыта.
Камера. На некоторых устройствах (например, на iPhone Pro Max 11) камера не работает. Также наблюдаются проблемы с камерой в следующих браузерах: Яндекс, Samsung Internet, MIUI. Мы понимаем что проблема в некорректном коде компонента камеры, но у нас пока не хватило опыта её исправить. Исправляем работу камеры на одном типе устройств — все ломается на другом. Если есть опыт работы с камерой,будем благодарны за помощь.
Несвободная лицензия MDB Vue в редакции Pro. Из-за отсутствия в команде дизайнера, нам пришлось подбирать UI-библиотеку. На этом этапе была допущена ошибка и из-за невнимательности при ознакомлении с лицензией мы не заметили тот факт, что лицензия MDB Vue Pro запрещает распространять под открытой лицензией проект с исходным кодом самой библиотеки MDB Vue Pro. Поэтому мы опубликовали варианты выхода из этой ситуации. Если вкратце, то можно написать несколько компонентов самостоятельно, удалить ненужные несвободные компоненты или вовсе использовать ХХК без фронтенда (например для написания ТГ-бота такой же направленности, как и ХХК).
Расширение для браузера. Для автоматизации отправки заявлений через формы уполномоченных органов, необходимо разработать простейшее расширение для браузера. Мы готовы оперативно проработать API для взаимодействия с расширением и в целом помочь в разработке, если будут желающие.
DevOps. На данный момент у нас нет CI/CD, Kubernetes, да и в целом есть масса замечаний по деплою. Например, у нас для каждой реплики бэкенда, поднимается свой контейнер с Celery в связке с Redis, что не очень хорошо. Также у нас нет автоматического масштабирования, что в перспективе может привести к проблемам с производительностью. Ну и есть масса замечаний к порядку развертывания. Например, при сборке для staging/production, статика фронта собирается в таком порядке:
Скрипт готовит папки на хосте перед запуском сборки;
Запускается контейнер для сборки статики Django;
Запускается контейнер для сборки статики фронта ХХК и фронта карты стоянок;
Уже после завершения работы трех контейнеров сборки, запускается контейнер с nginx, куда примонтированы директории с собранной статикой.
По-хорошему, нужно производить сборку backend, frontend, parkings_frontend, а потом уже при сборке Nginx копировать нужные директории/файлы из полученных образов.
Если есть опыт работы с Kubernetes и GitLab CI/CD, будем рады помощи.
Консоль модератора. Необходимы доработки в консоли модератора, а именно: фильтрация, сортировка, поиск.
Local-first. На данный момент у нас нет возможности работать при плохом канале связи на стороне клиента. Необходимо реализовать возможность работы с ХХК в режиме, близком к offline. Для этого необходимо переработать часть стора, чтобы он работал с IndexedDB, а также реализовать синхронизацию данных с сервером, не забывая про контроль за временем создания снимков (временем на устройстве), чтобы избежать подлогов (нужен «камертон», работающий через веб-сокеты).
Отправка заявлений от имени пользователей без доступа к их данным. На данный момент заявления отправляются от имени нескольких модераторов, что является одним из самых узких мест в проекте. Необходимо реализовать отправку заявлений от имени пользователей, но без доступа к их данным. Тут вариантов масса, но нам кажется идеальным следующее решение: мобильное приложение, которое помогает заполнять формы уполномоченных органов (если отправка ведется через формы), либо готовит черновик письма для отправки на почту уполномоченного органа через стандартный почтовый клиент.
Исправление логики импорта исходных данных. Сейчас все территории и базовые типы нарушений/полномочия и т.д. у нас импортируются в миграции, это неправильно. Во-первых, не всем нужны эти данные, а во-вторых, после импорта территорий производится их привязка друг к другу, которая из-за не оптимизированного кода и большого объема данных, требует для выполнения минимум 8Гб оперативной памяти и ~10 минут времени. Этот код писался на самом раннем этапе и мы тогда еще не знали про фикстуры и management-команды. Надо будет всю эту логику перенести в management-команду, чтобы она загружала из фикстур заранее подготовленные данные и импортировала их в базу, при необходимости загружая нужные картинки в S3-бакет.
Журналирование. Сейчас журналы пишутся в stdout контейнеров и, по сути, хранятся в огромном JSON-файле в одной из директорий docker-compose.Также мы настроили конфиги так, чтобы Nginx и Django их сохраняли еще и в папки, смонтированные на хост.
Мониторинг. Сейчас у нас помимо обычного хелсчека, на который стучится Traefik, чтобы определить жив ли контейнер при проксировании запросов,в файле с хелсчеками лежат представления, которые по сути не являются хелсчеками. На эти представления изредка заходит Uptime Kuma, чтобы мы в Телеграмме получали алерты если ресурсы хоста на исходе или что-то не так с бизнес-процессами (не уходит почта, выходят сроки модерации материалов, пользователь или модератор производят много отклоненных материалов). Все это по сути является метриками и необходимо это все, скажем, с использованием Prometheus, передавать на некие дашборды и от туда уже слать алерты.
Автоматизация бэкапов. Сейчас у нас все сервера бэкапятся средствами хостера + мы периодически выгружаем эти бэкапы себе в облака. S3 вовсе не бэкапится нами... Необходимо наладить нормальное резервное копирование и сохранять все добро в какой-нибудь сторонний ледяной S3.
Stateless. Сейчас у нас Stateful-архитектура. В частности, когда пользователь присылает фотографию нарушения, мы ее помимо S3, кладем в папку, примонтированную к хосту. После того как запрос успешно выполнился, запускаются фоновые задачи в контейнерах Celery. Одна из таких задач подбирает этот файл из той же папки, делает сжатую копию и стучится в Nomeroff, чтобы распознать номера. Контейнер Nomeroff ходит в ту же папку. В самом конце задачи, файл удаляется. Все это нам уже не очень нравится с архитектурной точки зрения.
Тестирование. Сейчас в проекте ровно 0 тестов. По-хорошему нужны не только юнит-тесты, но и нормальные интеграционные тесты.Также мы пока не научились производить нагрузочное тестирование, поэтому на все вычисления (на все серверы) у нас в сумме задействовано 10vCPU и 18Гб памяти, что требует ~7000 рублей в месяц. Нагрузочное тестирование позволит оптимизировать использование ресурсов и сократить затраты.
Дальнейшие возможности по улучшению ХХК мы описали выше, но из них хотелось бы выделить разработку мобильного приложения для возможности отправки заявлений от имени пользователей без доступа к их данным. С учетом реалий города Балаково, для начала будет достаточно простейшего функционала, который заключается в возможности авторизации, фиксации нарушений и отправки заявления с использованием настроенного в системе почтового клиента.
На Kotlin доводилось немного писать и в принципе есть понимание как это реализовать, но все упирается в отсутствие времени.
Исключение административных производств (и ХХК, как следствие)
Сейчас самое узкое место в нашем кейсе — это административные производства. По нашему опыту, больше 20 заявлений в один рабочий день это уже за гранью возможностей уполномоченного органа в городах, схожих с Балаково по населению. Для того чтобы понять почему так, давайте кратко опишу процесс:
Мы направляем заявление.
Это заявление регистрируют в отделе обращения граждан и относят главе в почту (о да, на бумаге!);
С учетом структуры аппарата, письмо «спускается» до исполнителя за 2-4 дня, т.к. каждый разбирает почту и «отписывает» (поручает) подчиненному в рамках возложенных полномочий;
Исполнитель готовит запросы в МВД (в ГИБДД и ФМС);
Эти запросы перед отправкой проходят ту же самую цепочку согласований, но уже «вверх», что также занимает 2-4 дня;
Запросы достаточно долго обрабатываются у адресатов (а бывает и теряются);
Приходит ответ на запросы и также «спускается» 2-4 дня. В идеальном случае в ответах есть контакты собственника авто;
Если контактов нет, то по адресу регистрации необходимо направить письмо (по тому же пути) касаемо административного протокола. Если контакт есть,то собственника приглашают на составление протокола (что тоже достаточно трудно и затратно по времени).
Когда протокол составлен, назначается административная комиссия, состоящая из уполномоченных лиц из разных ведомств. Как правило, комиссии проходили пару раз в месяц и на них приглашалось 20-30 нарушителей. Сейчас периодичность и «наполняемость», естественно, иные.
На комиссии каждого нарушителя по очереди приглашают, зачитывают ему протокол, дают слово, объясняют суть претензий и коллегиально принимают решение.
С учетом того, что все это выполняется «на бумаге», а также большая часть задействованных исполнителей делают это все в довесок к своим основным обязанностям, продуктивной такая модель работы стать не может.
Выход из этой ситуации — внедрение официального федерального приложения на базе ПАК «Помощник Москвы». Когда у нас получится добиться такого внедрения, потребность в ХХК отпадет и большая часть нарушений правил парковки будет проходить через эту систему в автоматическом режиме, что позволит комиссии заниматься другими делами, коих у них в достатке (свалка мусора, граффити, незаконная торговля, и т.д.).
Информационная работа
Также следует отметить необходимость продолжения информационной работы с населением. Даже сейчас, когда я пишу эту статью, нам приходят комментарии от горожан в стиле «на стоянках нет мест», хотя в самом посте четко указано, что это не так. Именно для этого, мы на базе ХХК сделали еще и отдельную карту стоянок. Это по сути отдельный контейнер Nginx со своей редакцией фронта.
Бэкенд используется тот же, только добавили отельные модели (1, 2, 3, 4) и сделали простейший эндпоинт.
Ну и напоследок, есть план действий на момент времени, когда все стоянки будут заполняться. В этот момент будем вести информационную работу с собственниками стоянок, ведь есть решения для увеличения их вместимости без строительства дорогих капитальных паркингов — роторные карусельные парковки.
Необходимо не упустить момент и сделать все для того, чтобы бизнес успел покрыть возрастающий спрос предложением, при этом не провоцируя новый виток роста уровня автомобилизации населения.
Код и компетенции
Лучший вклад, который вы можете сделать, это ваше время и компетенции. Поэтому если есть желание и возможности,мы будем рады предложениям и вашим MR.
Финансовая поддержка
Мы не принимаем прямые пожертвования на свою деятельность, но если у вас есть желание поддержать рублем, то вы можете внести вклад в оплату вычислительных ресурсов. TimeWeb позволяет любому желающему оплатить любую сумму, при этом необходимо выбрать опцию «оплата хостинга» и ввести имя домена хрюхрюкар.рф.
Информационная поддержка
Если вы владеете какими-либо информационными ресурсами и можете помочь привлечь внимание к проблеме, с которой мы боремся, напишите нам, нам есть что рассказать, чтобы более детально понять проблему.
Сайт: xxkap.app и хрюхрюкар.рф;
Почта брата — его зовут Игорь и он за время работы над ХХК неплохо вырос как бэкенд-разработчик, ~90% кода backend — его работа. Если кому-то в проект нужен молодой и перспективный backend developer (Django/Flask), напишите ему, пожалуйста.
Ну и насчет обзавестись друзьями: благодаря ХрюХрюКару, у нас теперь сотни (если уже не тысячи) классных друзей.
Все они занимают первые места в чемпионате по выдумыванию конспирологических теорий насчет наших источников финансирования, совмещенному с безуспешными попытками оскорбления авторов и участников проекта.
Жаль что они пока всё еще продолжают плакать, колоться, но упорно грызть кактус, который мы от них отодвигаем. Ну и ладно, мы будем все дальше плыть по течению этой занятной IT-реки с урбанистическим уклоном.
Спасибо за ваше время!