×Закрыть

150 технических специалистов, собственная ОС и 6 патентов. Как работает R&D команда Ajax Systems

Ajax Systems — украинская продуктовая компания, известная разработкой и производством умной беспроводной системы безопасности, которая защищает дома пользователей от вторжений, пожаров, затоплений.

Сейчас в штате 800+ человек. Есть R&D-офисы в Киеве и Харькове. Компания представлена также в ОАЭ, Великобритании и Польше.

Ajax Systems уделяют много внимания дизайну и интерфейсам, инвестируют в собственные аппаратные и программные технологии. В компании есть запатентованные решения: свои протоколы связи Jeweller и Wings, операционная система OS Malevich, алгоритмы в датчиках.

За разработку устройств и ноу-хау отвечает R&D-команда: она насчитывает более 150 человек и состоит из четырех отделов: Device, System, QA и Automation. Мы узнали, как работает каждый из отделов и какие задачи стоят перед ними

Как все начиналось

Идея разработки собственных устройств для охранных систем впервые появилась у CEO Ajax Systems, Александра Конотопского, в 2011 году. В то время Александр руководил компанией Secur — одним из крупнейших дистрибьюторов товаров для охранной сферы в Украине. Многие устройства Secur тогда закупала в Китае, и их качество часто хромало.

Однажды покупатели пожаловались, что сирена китайского производства прекратила работать через месяц после установки. Разобрав прибор с товарищем-инженером, Александр выяснил: звуковое устройство в нем было рассчитано на 2 ампера, а установленный китайцами транзистор — на 1 ампер:

«В этот момент у меня произошел разрыв шаблона. Китайский завод, где работает 400 человек, не мог разобраться в проблеме больше года. А мой одногруппник решил ее за 15 минут»

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

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

Линейка датчиков Ajax, какой ее знают современные пользователи, впервые появилась в 2015 году. На ее разработку ушло 3 года. Началось все c Jeweller — разработки проприетарного радиопротокола — базового ноу-хау Ajax. Jeweller обеспечивает большую дальность связи между устройствами, рекордные 2000 м на открытом пространстве, и энергоэффективность — датчики работают 5-7 лет от комплектных батарей.

Из устройств в линейке первыми появились датчики движения, открытия, разбития стекла и интеграционные модули. В 2016 году компания выпустила Ajax Hub, интеллектуальную централь, которая позволила объединить отдельные охранные устройства в охранную систему, а в 2017 году — новую операционную систему хаба OS Malevich.

Расширение продуктовой линейки Ajax

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

Компоненты для устройств заказывают у производителей со всего мира, однако все этапы производства — от монтажа DIP и SMD компонентов на платы до упаковки — происходят на заводе в Киеве. Так минимизируют использование аутсорса, сосредоточивая экспертизу внутри.

За последние 3 года объем производства Ajax Systems вырос в 13 раз и составляет более 250 000 устройств ежемесячно, а количество сотрудников на нем увеличилось с 45 до 500.

Сейчас система продается в 96 странах, ее используют более 500 000 человек. В Украине с ней работают не только частные компании, но и государственная полиция охраны.

Рассмотрим подробнее процессы в R&D-отделах Device, System, QA и Automation. R&D-директора каждого из отделов рассказали нам, как все устроено.

Device department

«Главные инженерные вызовы: Low Power, себестоимость и пригодность к массовому производству»

Этот отдел отвечает за разработку всех датчиков и устройств Ajax, софта для них, а также многих запатентованных технологий (например, протоколы Jeweller и Wings). Сейчас в команде 36 человек, и разработка новых устройств разделена на три основные направления: охранные устройства (датчики движения/вторжения), устройства home automation, пожарная безопасность.

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

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

Еще есть две подкоманды, которые организованы не по направлениям разработки, а по функционалу. Это команда hardware, что занимается разработкой плат. Сюда входят инженеры схемотехники и трассировщики, а также радиоинженер, отвечающий за радиочасть и электромагнитную совместимость. И команда mechanical — она состоит из конструкторов, которые разрабатывают корпусы и механику устройств, тест-стендов для масспрода и различные вспомогательные тулинги. Инженеры из этих команд на время, когда это требуется, подключаются к командам, разрабатывающим устройства.

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

Рабочий процесс

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

Максим, R&D-директор Device department, рассказывает: «Есть простые задачи, где есть один способ решения — например, при создании датчика воды. А есть случаи, когда задачу можно решить разными способами. Так, движение можно детектировать PIR-сенсорами, можно микроволновым сенсором на эффекте Доплера или сделать комбинацию. А когда стали разрабатывать уличные датчики, столкнулись с еще большими сложностями. Надо было придумать, как отфильтровать все помехи, кроме движения человека: ветер, движение деревьев, уличных животных, птиц, насекомых и так далее. В результате появился уличный датчик MotionProtect Outdoor — c нашим собственным двухэтапным цифровым алгоритмом предотвращения ложных тревог Lisa.

А потом пошли еще дальше и добавили фотокамеру в беспроводной датчик на батарейках. Получился MotionCam — датчик движения с фотоверификацией тревог. Для него разработали наш второй ридиопротокол Wings — он передает снимки менее чем за 9 секунд на расстоянии до 1700 метров от хаба. Чем дальше, тем более сложные устройства мы делаем».

После стадии ресерча лид устройства и команда презентуют свою концепцию перед широким кругом R&D-специалистов (делают некую «защиту проекта»). Так идеи проходят дополнительный фильтр и после этого дорабатываются.

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

Параллельно прорабатывают схему и пишут софт. В основном используют STM 8/32 і Embedded C. Далее разрабатывается плата.

«Затем, в зависимости от потребностей, мы можем напечатать на 3D-принтере корпус, а можем сделать его в хард-тулинге, то есть заказываем пресс-формы не на массовое производство, а попроще и подешевле — и отливаем прототипы из пластика. Допустим, световоды для системы антимаскинга. Их нужно сделать достаточно точно, тогда используют хард-тулинг. В результате получаем прототипы в финальном дизайне», — рассказывает Максим.

После этого прототипы проходят всестороннее тестирование разработчиками и QA. Если что-то не взлетает, переделывают и собирают новые прототипы.

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

Завершается все этапом бета-теста. Сперва идет закрытый — девайсы раздают сотрудникам. За ним стартует открытый бета-тест — для этого есть выборка активных пользователей (как в Украине, так и за рубежом).

Потом устройства передают в массовое производство.

Главные вызовы

Максим говорит так: «У каждого девайса всегда есть три основных ограничения:

  • Low Power — устройства должны работать максимально долго от комплектных батарей (5-7 лет) на расстоянии 2000 м;
  • себестоимость — мы делаем массовый продукт среднего ценового сегмента;
  • дизайн и пригодность к массовому производству — сборка должна быть простой и быстрой, а у ключевых компонентов должно быть несколько поставщиков.

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

System department

«Чтобы продукт был конкурентным на рынке, нужен engineering excellence»

Отдел отвечает за создание и развитие программных продуктов: OS Malevich, облачного сервиса Ajax Cloud, мобильных и десктопных приложений.

В отделе 28 человек, они делятся на 3 команды:

  1. Команда Apps разрабатывает десктоп, Android и iOS приложения.
  2. Команда Malevich создала и развивает операционную систему OS Malevich (у команды есть отдельный R&D Lead, о ней ниже).
  3. Команда CSA занимается разработкой серверов и их поддержанием.

Рабочий процесс

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

Дальше, как рассказывает Александр, R&D-директор System department, начинается анализ: «Садятся лиды, команды, которые будут участвовать в разработке проекта, и делают предварительное техническое задание — дизайн, архитектуру, протоколы, взаимодействие компонентов друг с другом. Когда есть первая итерация архитектуры, понимание объема проекта, происходит кик-офф — митинг, на котором мы рассказываем остальным членам команды, что это за проект с продуктовой и технической точки зрения, зачем он нужен и как собираемся его реализовать.

Затем согласовываем и планируем даты релизов таким образом, чтобы команды друг друга не блокировали, и берем уже технические задания непосредственно в работу (у нас Agile, но в зависимости от команды и периода это может быть или Scrum, или Kanban). Мы сильно печемся о качестве продукта и о качестве кода, поэтому, например, текущее требование на сервере — это покрытие автотестами нового кода не менее 90%».

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

По словам Александра, в команде CSA глубокая DevOps-культура: «Мы считаем, разработчикам важно понимать и заниматься операционкой, потому что задевелопить и „пусть оно как-то крутится“ — это хороший подход для аутсорсинга, но не для продукта. Продукт состоит из абсолютно всех частей — и разработать, и поддерживать, и убедиться в том, что он операционно правильно работает постоянно, не падает по ночам».

Технологический стек

На iOS — Objective C и Swift. На Objective C написана низкоуровневая логика по работе с проприетарным протоколом связи между хабом и сервером HtS, а весь пауер-код, всю хай-левел логику пишут на Swift. На Android тоже смесь Java и Kotlin, но потихоньку переписывают всё на Kotlin. На десктопе используют PyQT.

Сервер — это Java и Kotlin, для месседжинга — Akka, но переходят на NATS в новых проектах. Для хранения данных применяют MySQL, MongoDB и Redis — в зависимости от задачи. Вся инфраструктура в AWS, в амазоновском клауде. Используют Terraform и Bash, Python для ее автоматизации.

Главные вызовы

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

Александр рассказывает: «Ребятам, которых мы берем на сервер, на собеседовании задаем вопросы по базовым компьютерным наукам. Если человек использует базовые структуры, не понимая, как они работают, для меня это означает, что он и в дальнейшей работе не будет разбираться.

Для примера возьмем сервера: у нас сейчас нагрузка порядка миллиона пакетов в минуту, то есть приблизительно 17 000 в секунду. 300 000 TCP, подключений, постоянно висящих на наших серверах. Понятное дело, что есть определенные инструменты и подходы, которые могут уменьшать вероятность ошибки — performance testing, load testing и так далее. Мы все используем, но всё равно задача довольно масштабная».

OS Malevich team

«В основу новой ОС легла идея упрощения: добавление функциональности не должно снижать скорость разработки»

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

Хаб относится к System потому, что вся бизнес-логика выполняется на нем (в отличие от многих других систем, где делают очень простые датчики и сложные сервера, которые принимают решения). «Когда люди сталкиваются с системами Ajax, они удивлены, что у нас решения принимаются на объекте. Хаб на OS Malevich принимает решение о вызове группы быстрого реагирования, отправляет людям SMS, звонит, включает сирены. Автономность хаба — это наше большое преимущество», — рассказывает R&D-директор Сергей.

Почему решили разработать собственную ОС

Из-за проблем с надежностью Linux лучшие профессиональные решения на рынке не работают с ней. В команде тоже придерживаются этого мнения. Операционные системы класса RTOS рассматривали серьезно. По определению в таких системах либо результат нужен за 3 миллисекунды, либо он не нужен вообще. Поэтому RTOS используют в лифтах, автомобильных тормозах, баллистических ракетах, где критична сверхнадежность. Первая версия хаба, которая продавалась, была написана на RTOS, однако существующая архитектура не позволяла стремительно наращивать функциональность. В систему заложили апдейты, и уже в полях она заменилась на первую версию OS Malevich.

Как говорит Сергей, «в основу новой ОС легла идея упрощения. Мы поставили перед собой условие: добавление функциональности не должно усложнять систему и снижать скорость разработки. Чтобы не сбиться с намеченного курса, дали проекту кодовое имя „Малевич“. Реализовали схожий с Linux механизм распределения процессорного времени, в результате чего процессор хаба даже в ресурсозатратных задачах загружен максимум на 20%. Также сделали систему модульной (сама ОС это только 1 модуль из 70) со взаимодействием элементов через API. При этом компоненты, задачи в модулях не сражаются друг с другом за приоритетность „дай мне больше процессоров, больше времени, больше памяти“ или еще что-то такое. Всё сразу договорено на берегу.

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

Также адаптировали OS Malevich под работу ретрансляторов сигнала ReX. Это обеспечило Ajax еще большую автономность: если по какой-то причине радиосвязь с хабом прервется, ReX сможет частично принять управление системой на себя».

Рабочий процесс

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

Технологический стек

Сергей рассказывает: «В Embedded-мире используют С. Python для того, чтобы поддерживать мета-программирование. Система сборки — чистый Make, чем я лично очень горжусь.

Эффективность Мake просто потрясает. Если кто новый приходит в проект, он говорит: „Ну вот, сейчас я буду собирать эту прошивочку“, подключает сборку и собирается идти обедать. Не успевает повернуться, а оно уже закончилось. То есть Make не в разы, а в десятки раз быстрее соображает, что делать, а что нет. На Make удобно записать и зависимости между модулями, и размеры таблицы, исходя из хаба, страны, всякие частоты и прочее. Файлы Make простые для чтения и сложные для написания. В общем, очень его любим.

С++ не используем. Он избыточен — в данный момент нам не нужны его фичи. Еще одна неудобная для нас особенность С++ — неотделимость от динамического распределения памяти при появлении/уничтожении класса. У нас ресурсы распределены на берегу до выхода в море (благодаря этому для вирусов в OS Malevich просто нет места) — на С++ это плохо поднимается. Также одна из наших гордостей — это когда вы смотрите на хаб в приложениях, там нет кнопки „Перезагрузить хаб“. А если бы там был С++... Если эта кнопка появляется, это косвенно означает, что там С++. То есть хаб устает, каждые две недели его надо перегрузить до какого-то начального состояния. Нашим хабам перезагрузка не требуется».

Главные вызовы

Перед командой стоят три основных челленджа. Первый и главный: не ломать старое и создавать новое. Когда «Малевич» вышел на рынок, у продукта была очень высокая планка качества. То есть если один хаб из нескольких тысяч когда-то ночью вместо «мяу» сказал «гав», разворачивалась чуть ли не вся партия, всё разбиралось и переделывалось. Когда всё это вышло и начало продаваться, люди уже привыкли к этому качеству. И вызов, который стоит сейчас: следующая версия не может быть хоть в чем-то хуже предыдущей. То есть версия 2.10 должна быть во всем лучше 2.9, обладать той же стабильностью, а технически это часто довольно сложно. Когда добавляются новые фичи, всегда где-то изменяется весь проект.

Второй вызов — это бизнес-логика, которая все время усложняется. У разных стран есть требования законодательства, как должна вести себя охранная система. Сергей приводит пример Норвегии: «У них написано в законе, если один датчик пожара на объекте закричал, то всё остальное тоже должно закричать из солидарности. Идея в том, что один датчик в подвале или на чердаке, другой — в спальне, и датчик должен заорать, даже если пожар не в этой комнате, а где-то недалеко. Они прописали, и нам пришлось это делать для сертификации. Сегодня хабы это умеют».

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

QA department

«Информации, инструментов, специалистов для тестирования hardware не хватает. Все придумываем сами»

Сейчас в отделе около 40 человек: в нем прослеживается матричная структура. Каждый сотрудник входит в общую команду QA и подчиняется Head of QA. Дальше идет разделение на команды по направлениям: Apps, Malevich, CSA, Device и Prod Automation. В каждой команде есть свой QA-lead, и он уже непосредственно ею руководит. Также каждый QA входит в команду конкретного проекта и там он подчиняется проджект-менеджеру этого проекта.

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

Богдан, R&D-директор QA department, говорит: «Часто такое бывает, что ребята из Mobile находят проблемы в девайсах, а ребята из девайсов находят проблемы в мобильном приложении. Иногда люди из одной команды переходят в другую. Я считаю это важным. Если команды разделить, они начнут частично дублировать работу друг друга и не будут распространять опыт.

Все наши QA — выпускники технических факультетов. У нас обязательное условие приема на работу — технический бэкграунд, хорошие знания, понимание базовых вещей из физики и математики. Когда мы нанимаем Junior QA, то в качестве тестового задания даем задачи по физике и математике за школьный курс, 8-9-й класс. Также важно, что у нас QA — это не тестировщики, а скорее Developers in Test. Они разрабатывают продукты, которые тестируют другие продукты».

Рабочий процесс

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

В тестировании девайсов всё гораздо сложнее. Допустим, выходит новый датчик, и в требованиях написано, что этот датчик должен детектировать движение в диапазоне температур от −10 до +60 градусов. Тестировщик должен это проверить, а для этого проявить креативность. Например, летом, когда на улице +30, найти морозильные камеры для продуктов, договориться о том, чтобы для теста нашлась пустая, достаточно большая камера, там проверить, как датчики работают при −10 градусах.

У команды Богдана много интересных историй: «Мы тестили датчик движения, и нужно было зимой проверить, как датчик детектирует движение при +50. Эти тесты проводились в боксах для покраски автомобилей. Мы ездили, договаривались, чтобы выделили время для теста, нам нагревали целое помещение до +40 градусов и больше.

Также регулярно приходится ездить на Окружную, тестировать дальность радиосвязи (нужен чистый эфир и три километра прямой видимости). Вот был недавно забавный случай, когда наши ребята стояли возле дороги со всем расставленным оборудованием. Со стороны выглядит довольно странно: стоит группа людей возле машины, там антенны, разложенные ноутбуки, какие-то строки, логи, и в этот момент там собирался проезжать кортеж президента. Наша группа очень заинтересовала управление государственной охраны: они начали выяснять, кто мы, что здесь делаем. Хорошо, что они знали про Ajax. Просто попросили нас временно свернуться и отъехать оттуда».

Технологический стек

Главные инструменты — это C, Python и схемотехника. На Python пишут фреймворки для автотестов, при помощи С и схемотехники создают различные hardware-устройства и тест-стенды, что помогают в тестировании девайсов.

Главные вызовы

По словам R&D директора, основные проблемы — это отсутствие информации о том, как тестировать hardware-продукты, людей с готовыми знаниями и навыками, инструментов для тестирования.

Есть компании со схожей экспертизой, но они редко ею делятся — обычно такая информация под NDA. К тому же hardware-устройства между собой отличаются, подходы и инструменты тестирования тоже разные. Также сложно найти людей, обладающих знаниями в доменной области — таких людей просто нет. Все QA, которые работают в Ajax, выросли в компании с нулевого уровня.

Сложно и с инструментами: «Если мы, например, тестим web, для автоматизации есть куча инструментов. Если пытаемся автоматизировать серверные приложения, есть API. А для тестирования IoT в целом нет никаких готовых framework или устройств. И если разработчикам нужно просто разработать продукт/устройство, то QA разрабатывает десяток вспомогательных устройств, при помощи которых это устройство тестируют. Поэтому hardware-история такая: если разработчик делает какую-то фичу за час, то QA нужно 10 часов для того, чтобы ее протестировать», — делится Богдан.

Сейчас основное направление — это автоматизация. Команда сталкивается с тем, что количество продуктов Ajax растет, при этом нельзя перестать тестировать старый функционал. Разработчики делают новый, дополняют систему, и с каждым релизом нужно проверить весь новый функционал и весь старый. Время на тестирование постоянно растет. «Тестирование только одной OS Malevich занимает 2000 человеко-часов. Этот тест мы прогоняем перед каждым релизом. Пару раз было такое, что прогоняли более десяти раз полный регресс. То есть десять раз по 2000 человеко-часов — это уже получается около 20 000 человеко-часов. Абсолютно неадекватные сроки. QA становятся „боттлнеком“ в процессе релиза: разработчики сделали версию, QA её тестируют долго, а без тестирования охранную систему мы зарелизить не можем», — говорит Богдан.

Именно поэтому команда и делает упор на автоматизацию. Сейчас автоматизировали 35% общего количества тест-кейсов на OS Malevich. Все реализовано на реальном «железе» в условиях настоящего радиоэфира. Например, чтобы работать в радиоканале на базе OS Malevich разработали Jimmitator — имитатор датчиков Ajax, которые используют Jeweller для обмена информацией с хабом. Jimmitator позволяет работать с максимальным количеством устройств и предоставляет удобный интерфейс для одновременного управления ими.

Для упрощения мануального тестирования на основе ядра Ajax PRO был разработан QA Space. Эта среда дает возможность эмулировать различные части системы, генерировать ивенты, конвертировать информацию. На ядре Ajax PRO также функционирует фреймворк для автоматизированного тестирования сервера и хаба, который позволяет в удобном виде проверять работу системы на стороне клиент-серверной части.

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

Аналогичная ситуация в команде Device. Там специалистам приходится разрабатывать собственные устройства, которые тестируют датчики. Например, для DoorProtect Plus (датчик открытия, совмещенный с датчиком удара и наклона) разработан целый стенд с платформой, которую этот датчик наклоняет, проверяет, при скольких градусах детектирует наклон, имитирует вибрации, нажимает тампер, тестирует его радиоканал.

Automation department

«В любом финальном варианте можно что-то улучшить»

Отдел состоит из 11 человек. Здесь разрабатывают программно-аппаратные комплексы (тест-стенды) для тестирования каждого устройства в процессе производства, создают станки и роботов для автоматизации процессов сборки, а также внутренний софт для прошивки устройств и управления производством на всех этапах — от монтажа плат до упаковки готовой продукции. По сути отдел отвечает за то, чтобы производство в кратчайшие сроки могло поставить максимально качественный продукт в большом объеме. Благодаря их работе уровень брака на производстве составляет всего 0.3 процента.

По словам проджект-менеджера Антона, основное для сотрудников — ответственный подход к работе и умение быстро переключаться с одной задачи на другую. В отделе разрабатывают и поддерживают порядка 20 различных программ (не считая firmware автономных тест-блоков), и каждый разработчик должен в них разбираться.

Примеры разработок

Сейчас разработано около 40 типов различных стендов (в зависимости от датчиков), в общей сложности на производстве задействовано около 150.

Например, одна из разработок — обтискивающий станок, который повысил эффективность монтажа защитной решетки на корпусе уличной сирены StreetSiren в три раза. Есть тест-стенд, калибрующий 15 сенсорных кнопок клавиатуры KeyPad менее чем за минуту. А для проверки нового датчика с камерой MotionCam был разработан специальный тест-блок и софт с алгоритмами, что анализируют качество отснятых снимков в условиях дневного освещения и ночной съемки.

Рабочий процесс

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

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

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

Технологический стек

Используют 3-й Python и Embedded C. Python выбирали, потому что он проще всего в поддержке и разработке. Также изначально компания была знакома с этим стеком технологий: выбрали то, в чем уже есть экспертиза и с чем понимали, как работать. То же касается С.

Главные вызовы

По словам Антона, «основной вызов — это любой новый девайс. Разработка „железа“ — довольно итерационная штука. Даже если считаешь, что есть какой-то финальный вариант, скорее всего, в нем можно еще что-то улучшить. И когда команда Device улучшает что-то в своих платах, нам часто прямо на ходу приходится переделывать свои тест-блоки, изменяя параметры тестирования, чтобы выявить потенциально дефектные продукты, которые могут уйти с производства».

Итоги и планы

С 2015 года за все время разработки в компании сделали 29 девайсов, 7 основных обновлений устройств и 85 обновлений софта. Также есть 6 запатентованных ноу-хау решений.

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

LinkedIn

Лучшие комментарии пропустить

Что только не напишешь, лишь бы не отпускать персонал работать из дому.

С++ не используем. Он избыточен — в данный момент нам не нужны его фичи. То же наследование с удовольствием делаем на С и даже на Make и получаем то, что надо, без всяких проблем-ромбиков. Элементарно делаем двойное наследование и прочее к ужасу джавистов, у которых это запрещено. Еще одна неудобная для нас особенность С++ — неотделимость от динамического распределения памяти при появлении/уничтожении класса. У нас ресурсы распределены на берегу до выхода в море (благодаря этому для вирусов в OS Malevich просто нет места) — на С++ это плохо поднимается. Также одна из наших гордостей — это когда вы смотрите на хаб в приложениях, там нет кнопки «Перезагрузить хаб». А если бы там был С++... Если эта кнопка появляется, это косвенно означает, что там С++. То есть хаб устает, каждые две недели его надо перегрузить до какого-то начального состояния. Нашим хабам перезагрузка не требуется«.

аякс вычёркиваем как чисто технически недостижимый уровень чисто технической «грамотности» )) простите

Так-то молодцы, конечно. Но все же было бы неплохо попросить кого-то из 150 технических специалистов проревьюить статью, чтобы убрать совсем уж развесистую клюкву про суперэффективный make, кнопку перезагрузки в С++ и тд )

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

оно им просто не нужно
это основа их бизнес-модели — каждый месяц новый продавать

182 комментария

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Интересный материал, ребята с пониманием, понравилось.

Спасибо, познавательно

С++ не используем. Он избыточен — в данный момент нам не нужны его фичи. Еще одна неудобная для нас особенность С++ — неотделимость от динамического распределения памяти при появлении/уничтожении класса. У нас ресурсы распределены на берегу до выхода в море (благодаря этому для вирусов в OS Malevich просто нет места) — на С++ это плохо поднимается. Также одна из наших гордостей — это когда вы смотрите на хаб в приложениях, там нет кнопки «Перезагрузить хаб».

SpaceX пише прошивку для ракет на С++ і все чудово літає і навіть без кнопки резету %)
Може все ж не у плюсах справа)?

Може, в ракеті чіпи трохи дорожчі, ніж в ІоТ сенсорах?

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

Комент був більше про те, що писати с++==кнопка ресету, це, як мінімум, непрофесіоналізм.

Це ж зовсім інше. З іншими вимогами, залізом, напрямком, фінальною вартістю проєкту та продукту.

З певних причин нам не підходило рішення на С++, тому зробили саме так. Але це не говорить про те, що рішення погане, або щось подібне.

Просто трохи дивно був поставлений акцент у статті, який, особисто я, прочитав як с++ = нестабільне рішення.

Технологія це досить другорядна річ, перш за все важлива надійність і ефективність прокладки між стулом і клавіатурою )

Зрозумів, дякую за роз’яснення. Так не повинно було зчитуватись. Просто рішення трохи не підходило з деяких причин.

Також вважаю, що технологія це лише інструмент досягнення цілі або розв’язання задачі. А вже ці задачі можна вирішувати багатьма способами.

Который раз вижу рекламную статью про Ajax. И который раз наблюдаю мастерский обход темы разработки фирмвари для датчиков. К чему бы это?

На самом деле никаких ни заговоров, ни мастерских обходов нет.
Тему разработки фирмвари очень подробно разбирали на митапе, который Ajax организовывал:
dou.ua/calendar/30368
а раскрывать данную тему в статье не целесообразно: маркетологи этого не напишут, а у разработчиков своя работа есть, плюс потом надо кому-то отвечать на кучу тех. вопросов в комментах, а разработчики опять же заняты.
Приходите на митапы — все узнаете, в живую пообщаетесь с людьми которые те самые фирмвари делают.

Т.е. про хабы с самописной ОС рассказать — время есть. А про богов низкоуровневой отладки и властителей битовых полей — нет времени. Заняты разработчики. Т.е. загружены сверх всякой меры. Ясно, понятно. Спасибо.
~ЗЫ: Вы хоть из подвала их выпускаете?~

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

Грустные они у Вас какие-то
Может, из-за опенспейса

Ну почему грустные? Просто свой круг интересов.

Выпадают из сообщества. Как любят говорить в лидерах рынка, «нужно развивать софт скиллы».

А если применить древнюю пионерскую магию чтения между строк, то у вас там написано «сроки горят, не до коммментов на ДОУ».

Может, всё же, людям, действительно, есть, чем заниматься? Иногда банан — это просто банан :)

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

оно им просто не нужно
это основа их бизнес-модели — каждый месяц новый продавать

хороша система, але ціни поза україною жесть. розетка за 100 євро? штора за 150? це п**ц

Вибачте, але де ви такі ціни побачили? 1099 грн за розетку це вже багато років не 100 євро.

і де в німеччині, нідерландах чи бельгії замовити розетку аякс за 35 євро? бо я бачу лише по 100, і купу від фібару (теж пристойна якість і відомий бренд) на зетвейві по 50-55, тплінків на вайфаї по 20 і кетаю по 10-15.

Ось тобі готовий бізнес Дрю :)

пушати товар в торгові мережі замість інсталяторів? чи возити бусами товар в європу? навіщо мені возити контрабасом товар не відомої фірми з третього світу?

пушати товар в торгові мережі замість інсталяторів? чи возити бусами товар в європу? навіщо мені возити контрабасом товар не відомої фірми з третього світу?

Ти же знаєш відповідь :)

Может быть потому что

поза україною

?

і? елаборейт пліз

наша ціна відвантаження дистриб’юторам мало відрізняється поміж ринками. далі накладаються реалії локального ринку професійного охоронного ринку, де кожна ланка далі може мати різну маржу.

я це розумію. не до кінця розумію чому в україні це розетка а в європі професійні охоронні компанії. але це не відміняє факту з реальності — фібаро 50, аякс 100. я ще десь розумію різницю ціні централі (але вона не в 2.5 рази дорожча а всього десь на 50 відсотків) бо це професійний девайс в певній мірі, але що виправдовує різницю ціни розетки?

Так это наверное хорошо, значит покупают по 100 ;) Печенье Рошен вон в Калифорнии по $1.10, а в Киеве по $0.30.

да нєт навєрноє. просто на ринку ціною рулять інсталятори (яких вибрали каналом продаж). їм по барабану продається та розетка чи ні. порівнювані за якістю/можливостями продукти коштують приблизно однаково. хіба ні?

пєчєньє рошен в каліфорнії розвага для ностальгуючих фріків а не полочний продукти в супермаркеті. воно може легко бути і по ціні кокаіну

Так это наверное хорошо, значит покупают по 100 ;) Печенье Рошен вон в Калифорнии по $1.10, а в Киеве по $0.30.

буть того не може, на доу всі знають що в каліфорнії все дешевше ніж в києві.

женя ти взагалі читаєш перед тим як відповідати? це як печиво світоч по 50 гривень а печиво рошен по 100. на одному і тому самому ринку. бо світоч продають в магазинах. а рошен через мережу бутіків «перша каліфорнійська копальня печива» де спеціально обучений аніматор зтанцює ча-ча-ча в процесі упаковки або розкаже красіву лігєнду для л̶о̶х̶а̶ туриста. тож моє питання «чуваки а не можна частину печива завозити і в магазини?»

Я про те що сама думка про умови локального ринку — крамольна.
сарказм моде офф

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

Разве в Украине делают процессоры?

До недавнего времени в Украине и датчики безпастности не делали. Они же могут начать делать не только

процессоры

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

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

Я представляю, потому что ходил на радио-технику некоторое время (отдаю себе отчет, что это всё прошлый век, но всё же). Разве в Украине нету ни одного предприятия, которые может что-то подобное делать? Как же эти все УкрОборонПромы?
Опять же баналько корпуса из пластика освоить Украина может же?

УкрОборонПромы

А знаешь, сколько нужно заплатить за откаты? Его потом только в Администрацию Президента продавать.

Разве в Украине нету ни одного предприятия, которые может что-то подобное делать? Как же эти все УкрОборонПромы?

На медяшку попилено все старое, впрочем было бы живо — мало чем бы помогло, закон Мура никто не отменял.
Нового ниасилила даже купающаяся в нефтебаксах Раша. Слишком сложный и разветвленный технологический цикл.
Впрочем даже в Штатах половина производителей полупроводников — фаблессы, с «отшивом» в том же Китае.

Опять же баналько корпуса из пластика освоить Украина может же?

Делают. Но там свои нюансы. Скорее всего выходит ощутимо дороже.

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

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

по идее 8080 и 8086 ещё делают ))

На Квазаре, вроде, делали/делают

Все можно) Вот, например, в Переяславе — почти построили завод Точмаш в конце 90х — как раз для производства плат, в т.ч. для ракет. Можно завершить постройку, если кому интересно)))
Из существующих — Vdmais делает сложные платы

Просьба добавить Ваше приложение в AppGallery.

Так-то молодцы, конечно. Но все же было бы неплохо попросить кого-то из 150 технических специалистов проревьюить статью, чтобы убрать совсем уж развесистую клюкву про суперэффективный make, кнопку перезагрузки в С++ и тд )

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

На моей памяти было 2 подобных случая:

1) Поставщик батареек начал подмешивать нам брак. Затем у клиентов в полях начали датчики быстро садиться. Мы собрали обращения, всё проверили и поняли, что дело именно в батарейках, а не завышенном потреблении или чём-то другом. Сменили поставщика и ввели 100% контроль всех батарей перед установкой в девайсы.

2) Мы осенью выпустили уличный датчик движения типа «штора» MotionProtect Curtain. Осень и зиму мы получали положительный фидбек, но весной и летом начались замечания: в редких случаях датчик выдавал ложные сработки системы маскирования из-за насекомых. Мы решили не рисковать доверием к нам и партнёрам, поэтому решили действовать.

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

— Снизили стоимость
— Доработали софт и сделали девайс для использования только внутри помещений
— Адаптировали материалы, проинформировали инсталляторов, дистрибьюторов, охранные компании и других партнёров

У кого всё работало хорошо: датчик и дальше работает. У кого были замечания: предлагали обратиться в саппорт. Если проблема не решалась — возврат средств / замена устройства.

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

До речі, маю 2 запитання:

1. Чи розглядає давачі з підживленням від energy harvesting джерел (наприклад, сонячна батарейка + peak controller + supercap), для збільшення часу роботи без заміни елемента живлення?

2. Чи плануєте використовувати мікроболометри з низькою роздільною здатністю (наприклад, 8×8) для зовнішніх давачів руху? Мені здається, що ціни на такі сенсори суттєво знизилися за останні 5 років. Хибні спрацювання (тварини, рух інших об’єктів) фільтрувати було б значно легше. А за одно була б унікальна пропозиція на ринку.

Поки що не готовий відповісти на ці питання.

Тепер готовий.

1) Поки не плануємо: реалізація значно збільшить ціну девайсів. Також є питання до реалізації.

2) Поки що не розглядали такий варіант. Дякуємо за підказку.

С++ не используем. Он избыточен — в данный момент нам не нужны его фичи. То же наследование с удовольствием делаем на С и даже на Make и получаем то, что надо, без всяких проблем-ромбиков. Элементарно делаем двойное наследование и прочее к ужасу джавистов, у которых это запрещено. Еще одна неудобная для нас особенность С++ — неотделимость от динамического распределения памяти при появлении/уничтожении класса. У нас ресурсы распределены на берегу до выхода в море (благодаря этому для вирусов в OS Malevich просто нет места) — на С++ это плохо поднимается. Также одна из наших гордостей — это когда вы смотрите на хаб в приложениях, там нет кнопки «Перезагрузить хаб». А если бы там был С++... Если эта кнопка появляется, это косвенно означает, что там С++. То есть хаб устает, каждые две недели его надо перегрузить до какого-то начального состояния. Нашим хабам перезагрузка не требуется«.

аякс вычёркиваем как чисто технически недостижимый уровень чисто технической «грамотности» )) простите

Конечно, почти на любой платформе и языке можно решать любые задачи. И на ассемблере сайты пишут. Но нам C++ не подходил по ряду причин. Это не значит, что решение плохое. Это значит лишь, что оно не для нас.

На C++ можна написати все те саме що й на С й отримати з коробки нормальну перевірку типів, перегрузку й метапрограмування. Одна з базових ідей плюсів — не платиш за те, що не використовуєш, тому від динаміки за потреби можна відмовитись.

Наприклад, система без хіпу (1 KB RAM) й з обмеженим ROM. Навіщо туди тягнуть С++?

Ну например сконструировать все на старте в виде пула и объектов и потом не трогать. Я такое даже на Джаве видел.

Реальная проблема не техническая, а психологическая. Придут адепты труЪ++ и навешают на каждый чих исключений, а потом взалкают 20-й стандарт.

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

Про 20 стандарт туда же. Вот он вышел — значит нужно использовать всё из него. Видишь где-то #include в коде — срочно переводи проект на модули, иначе не труЪ.

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

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

P.S. Кстати о Rust в подобных системах очень хорошие отзывы.

Можно подумать, что это возымеет действие.

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

Знаем, плавали.

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

На адекватного человека — вполне.

Адекватный человек понимает, что Plain Old C может и потянет немножко больше времени в наборе кода, зато уж точно не станет причиной трудноуловимых ошибок на рантайме.
А с отладчиками, напомню, на подобных платформах — жопа. И если можно выкинуть строку в UART это можно сказать люксовая опция. Увы, в hard-realtime UART может очень серьезно повлиять на скорость выполнения.

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

Наприклад, щоб змайструвати симулятор й обкласти все тестами не обмежуючи себе ні в чому. Втім, наврядчи у них там 1 КБ.

Не зрозумів. Яким чином коригує те, написана прошивка на С чи на С++, до можливості підключення симулятора?

Та не підключення, а тестів у софті.

Тести в прошивку ніхто не пхає. Їх хоч на Пітоні писать можна.

Можна розбити полотно С кода на класи, неймспейси, темплейти замість макросів, більш строгі правила приведення типів. С++ не означає обов’язково віртуальні функції, динамічну пам’ять і т.д. Ми писали бутлоадер на 16-бітному С++: влазило в 512 байт, з виводом менюшки на екран, обробкою клавіатури — ніякого оверхеду.

Чим Вам там допоміг С++ порівняно з С?

Більш структурований код, більш зручні підказки від IDE. Наприклад, клас String і в ньому всі методи по роботі зі строками. IDE це парсить і видає список методів.

Класичний String буде покладатись на хіп. І навряд чи на 512 байт буде серйозна робота зі строками. Там бодай на стек вистачило б.

Ні, всі класи свої. Забув ще додати — деструктори: наприклад, можна запам’ятати поточну позицію курсора в конструкторі, а в деструкторі повернути її на місце.

Ні, всі класи свої.

А це потребує часу. Якщо там написати 1-2 датчика, то простіше на С зробить і забуть, ніж на С++ вкладатись у власну бібліотеку.

Можна зробити стрінг без хіпа, який буде обмежуватися місцем, доступним всередині самого об’єкта. Ще можна зробити цей максимальний розмір параметром темплейта, для більшої гнучкості (вийде такий собі стрінговий аналог boost::static_vector).
Або можна зробити стрінг, який буде посилатися на контент за межами об’єкта (а ля std::string_view).
Варіантів багато.
Якщо проаналізувати, як себе поводив сішний код, що реалізував цю логіку, можна написати плюсовий аналог, який для деяких девелоперів виявиться зручнішим та/або безпечнішим без зайвих оверхедів.
Інше питання, чи потрібно це на конкретному проекті. Якщо проект не дуже великий, то, як то кажуть, гєморой нє стоіт свєчь.

Ще можна зробити цей максимальний розмір параметром темплейта, для більшої гнучкості

 Я для телефонії собі так зробив. А в датчик це пхати сенсу нема, бо там і строки не потрібні, думаю.

Можна все. В цьому й сенс технологій: задачі можна вирішувати декількома способами. А рішення не стає гіршим чи кращим від вибору методу реалізації.

Ми проаналізували варіанти й зробили так, як підходило саме нам. Все працює, працює стабільно, система масштабується, а компанія продовжує працювати.

Не подходил по ряду причин — конечно, можно понять. У плюсов много своей специфики, которая действительно далеко не каждому проекту подходит.

Но вот это вот

Еще одна неудобная для нас особенность С++ — неотделимость от динамического распределения памяти при появлении/уничтожении класса.

— не причина.
Это просто демонстрация некомпетентности человека, который писал данный абзац.

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

Но это больше исключение, чем правило.

Очень спорное утверждение. Если в C++ классе/структуре нет полей или базовых подобъектов, которые нуждаются в динамической аллокации, то и сам этот класс ничего аллоцировать при конструировании не будет.

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

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

А так да, с субъективными предпочтениями я спорить не собираюсь. «Я выбираю C, потому что больше его люблю, а вот C++ мне не нравится» — это вполне understandable.
Но вот «я выбираю C, потому что C++ обязывает меня использовать динамическую память» — плохой аргумент.

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

ну реально, если прочесть — цитата полна треша более чем полностью ))) вот что случается когда технический текст пишет тот, кто не шарит )))

Из чего, простите, вычеркиваем? Из потенциального места работы? Из списка покупки охранную систему? Из?...

Интересно, сколько длится цикл разработки: от ТЗ до отгрузок клиенту?

Сильно зависит от устройства. Что-то простое или там где технологии уже наработаны — за полгода справляемся. Самые сложные девайсы занимали полтора года.

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

Сказал человек, который работает в компании-монополисте из за которой цены на электроэнергию у нас выше чем в странах ЕС)))))

У нас природная монополия. В курсе что это такое? По поводу цен на электроэнергию. Тебя кто-то жестко обманул — цены в Европе выше, чем у нас. По поводу «из-за которой» Доля тарифа Укрэнерго в структуре цены для конечных потребителей составляет менее 10%. Можешь чем—то подтвердить свой наброс, что именно «из-за которой»? Ты вообще в курсе как цена на электроэнергию формируется? И последнее, к чему вообще ты полыхнул, если речь шла про удаленную работу во время карантина?

Це така квінтесенція брехні, персонального наїзду, переводу стрілок і т.ін., що навіть вагаюсь в виборі: Шарій чи СН? :-D

Какой Европы? В Германии потребление 250 кВтч в месяц обходится в 80 Евро. Обычная стоимость кВтч около 0.28 Евро. В Украине примерно в 5-8 раз (зависит от объемов потребления) дешевле.

P.Sю В Германии вроде бы самая дорогая в ЕС энергия потому что вся вечнозеленая, гендернонейтральная и что-то там еще. Но, если уж говорите за Европу, то уточняйте. А то мне сдается, что европа, в которой электроэнергия дешевле, чем в Украине, существует только в голове Юлии Владимировны.

зачем нужно было врать что ajax это Чехия? мы когда ставили охранку нам дали на выбор системы — Украина, Китай и Чехия (ajax)

А кто вам соврал? Представитель охранной компании?

Спасибо. Я уже передал это ответственному менеджеру. Найдём виновного, проведём беседу. Подобное больше не должно повторяться. Возможно есть какое-то недоверие к нашим системам, но с этим нужно бороться.

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

А еще у них веселая реклама youtu.be/lj1xfcZ6kMA?t=1173

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

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

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

закрываться не планируем уж точно

никто не знает, что будет завтра. кто в прошлом году предвидел эпидемию планетарного масштаба?

Тыквы не будет

приложение в смартфоне превратится в тыкву. я правильно понимаю?

никто не знает, что будет завтра. кто в прошлом году предвидел эпидемию планетарного масштаба?

Согласен. Но с таким успехом могут закрыться и сервера Amazon и половина сервисов по всему миру канет в лету. Может закрыться Steam, и ничего нельзя будет скачать. И так далее.

приложение в смартфоне превратится в тыкву. я правильно понимаю?

Приложение работает через сервер. Без сервера оно не работает. Но и у полностью автономных решений есть свои особенности в работе.

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

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

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

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

Но решать всегда вам — подходит ли вам подобное решение, или нет.

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

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

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

Ви порівнюєте запас міцності Amazon чи хоча б Steam та Ajax? Вважаєте, вони одного порядку?

Ну у стіма 125 мільйонів користувачів, у нас 500 000. Трохи інші масштаби :)

Але я не про це. Моя думка — зараз майже всі сервіси зав’язані на хмару. За цим майбутнє. Амазонівськи сервіси, стім, нетфлікс, PSN. Все, про що зараз говорять люди.

Але всі ці сервіси мають підписки. Саме на це й вказував Олександр. Якщо ваші продажі раптом впадуть, а база клієнтів вже буде велика, вам доведеться або відмовлятись від хмарного сервісу, або вводити додаткову абонплату навіть для вже існуючих клієнтів. Зараз це виглядає як пирамида, коли підтримка централізованого сервісу йде за рахунок грошей, які ви отримуєте від поточних продажів.

Можно ли к вам прийти без опыта работы и какие требования со старта? Интерншип или что то такое есть?

Привіт, Оксано)
Так, дуже раді молодим талановитим інженерам:) Частіше всього відкриті позиції у команду тестування, зараз є вакансії у київський та харківський офіси — jobs.dou.ua/...​systems/vacancies/120696
jobs.dou.ua/...​systems/vacancies/123025
Періодично шукаємо розробників без комерційного досвіду у Embedded C або Python. Головні вимоги: технічна освіта, наявність власних завершених навчальних проектів, хороші навики програмування на С чи Python, бажання розвиватись у цій галузі і хотіти створювати щось нове)
Не так часто, також трапляються вакансії інженерів-конструкторів, Hardware розробників, Junior Project Manager. Всі актуальні позиції можна переглянути тут — ajax-systems.breezy.hr
Який напрям вам більш цікавий?

Оксана, если вы конечно не пиар менеджер данной компании, советую вам внимательно прочитать данные статьи — ******.it/tag/ajax-systems/ и решить, надо оно вам или нет.

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

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

Богдан, если вам только не 3 года, то вы уже имеете некоторый жизненный опыт, и сможете субьективно отделить правду от неправды, и разбираться в полутонах информации, которую могут написать на том-же итальянском сайте.
Даже не обязательно читать то, что пишут о вашей компании другие люди. Их мнение может быть таким-же субьективным, и не всегда можно видеть всю картину.
Однако можно просто посмотреть на том же итальянском сайте интервью в вашим директором Александром. Оценить его манеру общения и просто его действия, про которые он сам рассказывает, и которые сделали Аякс в общем, и Александра в частности, более популяным на ДОУ и итальянском сайте. Тут уже врядли можно что-то списать на искажение передачи информации через «вторые» руки или чью-то «обиженость».

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

мне кажется количество комментариев на ДОУ в рабочее время некоторых комментаторов говорит больше всего)

Добро пожаловать, тут всегда так :)

Что только не напишешь, лишь бы не отпускать персонал работать из дому.

Да, дуже показова ситуація про відношення компанії до співробітників. Я б після такого навіть і не подивилась в бік їхніх вакансій

Помню, мне до всего этого зашквара с карантином даже пару раз писали с данной компании. Однако, заценив их местоположение (до метро\трамвая далеко, не уверен, что туда вообще какой-то транспорт ходит), понял, что работать там не хочу. После данной истории, и странной позиции «страдать от коронавируса будем все», понял, что мне с ними не по пути.
Ну а после историй с инсайтами на «итальянском» сайте, понял, что пронесло :)

Могу поинтересоваться почему на своем протоколе, а не на тех же Zigbee или Zwave?

а вони бьють надійно на таку відстань?

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

А как протокол влияет на дальность? Вы собственную радиочасть сделали?

Протокол влияет на дальность. Давайте попробую объяснить.

Дальность зависит от мощности передатчика, чувствительности приемника и шумов в эфире. Если первые две величины постоянны, то шум в эфире всё же зависит от ширины канала.

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

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

Затем на логическом уровне мы внедрили систему повторов, которая повышает вероятность доставки команда, когда это нужно. Таким образом, мы получили нашу дальность в 2000 метров на открытом пространстве.

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

Дальность зависит от мощности передатчика, чувствительности приемника и шумов в эфире

Все, что вы назвали имеет отношение к PHY, а не к протоколу. У вас собственный RF? Или это попытка тюнинга 802.15.4 и 802.15.4 sub-ghz? Упомянутый вами самописный ARQ вполне можно запустить поверх существующих L2 протоколов. С длиной пакетов тоже самое — ничего не мешает использовать кастомный device profile с уже существующими IoT протоколами.

Можно. Но чем это решение будет лучше?

Дальность зависит от мощности передатчика, чувствительности приемника и шумов в эфире

выбранной модуляции, усилении антенн, частоты...

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

Так версия 1.0 у них вышла в 2015 году. А мы были пораньше.

Почему своя ОС а не например QNX?

подробнее о том, почему сделали свою ОС, можно глянуть тут ajax.systems/...​og/hub-os-malevich-story

Там не написано, почему отказались от QNX в пользу своей ОС. Там написано, почему не выбрали Linux.

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

Можно конкретику?
Еще есть uCOS, FreeRTOS и всякие другие. И с раундробином есть.

А чем именно не подходило? Вроде серьезная и надежная RTOS.

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

Мы системно подходили к этому вопросу. И после составления NFR увидели, что решения, которые есть на рынке (как Линукс и QNX) нам не подходят.

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

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

Вы пишите, что по NDA не можете сказать, почему не подходят, но в тоже время у вас это опубликовано на сайте: «киберуязвимости, отсутствие временных лимитов у операций, стандартные и, зачастую, не лучшие драйвера»

Это про Линукс написано. Если вкратце — как я уже говорил, она разрабатывалась для других задач. Также QNX платная и со сложными лицензиями.

Но я не понимаю предмет спора. Да, систему можно сделать на QNX. Да, мы сделали своё решение, а не брали Линукс / QNX или что-то другое. Да, оба решения имеют право на жизнь.

Да мы уже разобрались, что ваша «ОС» нужна чтоб диодами играть, так что больше обсуждать нечего.

Ну это как сказать, что iOS 14 нужна только чтобы звонить маме. Позвольте уточнить, вы системой пользовались?

Ну скажи что RTOS не ОС

Серьезная и надежная QNX сильно избыточна для задачи помигать светодиодом.

А кроме как мигать других задач нет?

А какие еще?
Проснулся по таймеру, прочитал инпуты, принял решение, поставил в очередь на исполнение, «bottom half» проверила бит готовности UART/SPI/I2C/GPIO, если предыдущая команда выполнилась, выбираем из очереди следующую и отправляем в IO регистры, уходим спать.
В общем случае все пишется за два дня на коленке, ранится на любом микроконтроллере даже без привлечения DMA.

А, ну тогда понятно что это за «ОС» :)

Это да :)
Зато потребление микроамперное.

Не знаю. Я с переходничком USB<->SLIC месяца 3 мучался, и потом еще пару месяцев допиливал, когда оказалось, что USB у хоста может тормозить и надо прерывания SLIC обрабатывать на плате. При этом ПМ и с осциллографом сидел, и голосовые пакеты мерял — мне только кодить оставалось. Правда, раньше железки не поднимал — кто опытный быстрее сделает, но за два дня — очень вряд ли.

Да, железо иногда выкидывает номера. Я тут недавно с LTE модемом сношался, ощутил себя младенцем в джунглях, хотя первые АТ команды набрал еще в прошлом веке.

Я не работаю в Ajax, но все же готов с собственного кармана оплатить вашу работу. Рейт $100/час. Два дня. Операционная система, которая обеспечит работу всех функций на всех существующих девайсах Ajax, в продакшене, на десятках тысяч клиентов, и, конечно, вы лично оплатите исправление любых багов, замену устройств в случае невозможности исправления софта «по воздуху», репетиционные потери и все остальное, связанное с надежностью.

но все же готов с собственного кармана оплатить вашу работу. Рейт $100/час. Два дня.

Серьезно? С пустым профилем? Ох уж эти доморощенные пиарщики.

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

Еще раз.
А анонимами в технические дискуссии не вступаю, а тем более пари не заключаю.

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

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

Я не работаю в Ajax

И никак с ним не аффилированы? Совсем-совсем никак?

1. Вопрос в самом начале ветки

Почему своя ОС а не например QNX?

2. Ссылка на сайт компании, где объясняется почему они отказались от существующих ОС, чтобы создать ОС, задачами которой являются, цитата
«Мы создали навороченную ОС, поддерживающую продвинутые протоколы связи с облаком по нескольким каналам, управляющую сетью из сотни радиодатчиков, способную одновременно отправлять тревожные сообщения по IP—каналам, звонить и слать SMS, поддерживающую устройства автоматизации. Обладающую всеми необходимыми профессиональной охранной системе возможностями и защищенную от атак»
3. Проффессионал заявляет, что QNX

избыточна для задачи помигать светодиодом

Хотя в ссылке нет задачи мигать светодиодом, зато есть целый перечень довольно сложных задач.
4. Вопрос к нему ниже

А кроме как мигать других задач нет?

5. Утвердительный ответ и лепет о какой-то поделке, но функционал этой поделки этот проффессионал приписывает решению от Ajax, мол, это как раз то, что и делает ОС Малевич.
Ну раз за два дня человек может создать ОС равную ОС от Ajax, я готов ее оплатить. Именно за два дня, именно production-ready, именно на железо тысяч клиентов. Хотя, понятно, что это просто детский садик, никакую ОС, тем более уровня Малевич, никто за два дня не создаст, это сказки с падиков, хорошо характеризующих уровень профессионализма заявителей.

И никак с ним не аффилированы? Совсем-совсем никак?

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

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

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

Описание — если ему, конечно, пытаться верить хотя бы в основе — показывает нечто, что ни с обсуждаемыми аналогами (Linux, QNX), ни со стандартным понятием ОС не соотносится никак, зато соответствует концепции некоторого движка событий с клиентами, кооперативной многозадачностью и хорошо развитым специализированным стеком протоколов. И всё это сопровождается детскими сказками типа «в RTOS результат нужен за 3 мс», хотя реальные RTOS очень разные, и уровень гарантий реалтаймовости (harm/firm/soft + квантили гарантий) разнятся на порядки, для каждого нужны свои методы, и 3 мс это цифра вообще из рассказа про 500 mile email (реально где-то потребуют и 100 нс, и это вполне выполняется, а где-то и 5 секунд пофиг, если речь про подробный рассказ состояния для отладки).

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

Хотя, понятно, что это просто детский садик, никакую ОС, тем более уровня Малевич, никто за два дня не создаст, это сказки с падиков, хорошо характеризующих уровень профессионализма заявителей.

Сказки пока что со стороны вас и Ajaxʼовцев — назвать ОС пусть даже хорошо проработанный, но целевой стек реализации своих протоколов. (Ну, возможно, где-то в углу притулился TCP — в самой скромной версии, даже без Reno, потому что нафиг не нужен для передачи 1 килобайта на соединение.)
И вот ваша синхронность в этом назывании показывает, что рассказы про вашу несвязанность с Ajax надо, мягко говоря, делить на 3.

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

Они, конечно, не первые — Cisco IOS (времён до XR) была раньше, и её проблемы от такого подхода известны всем, кто хотя бы немного юзал кошкину технику :) SNMP в 12.0 я помню до сих пор :)

Готов поверить, что это не так — но на основании хорошего технического рассказа (найдётся, как проверить).

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

Мерси.

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

Ну, возможно, где-то в углу притулился TCP — в самой скромной версии, даже без Reno, потому что нафиг не нужен для передачи 1 килобайта на соединение.

Там притулился GSM-модем SIM800, который по своей начинке вероятно на порядок сложнее всей остальной платы.
www.ixbt.com/...​3/37/set/set/119/00-4.jpg
wireless-e.ru/radiomoduli/sim800x

Спасибо вам за то что вы есть!

Уххх, очень мощно! Описан какой-то запредельный уровень создания хардверных продуктов. Жаль, что в вузах так не готовят

та вообще то в кпи на ртф готовили именно так, не вижу ничего нового в статье

как человек, который сам заканчивал НАУ (радиотехника), скажу: программа и оборудование для лабораторных работ конечно безбожно отстают, но основы которые дают в вузах, на то и основы чтоб всегда оставаться актуальными. Поэтому если вникать в профильные предметы в ВУЗах, разбираться в лабораторных, а не сдавать их для галочки, то после получения диплома сразу же крутым разработчиком Вы конечно не будете, потому что тут опыт нужен, но попасть на работу и очень быстро во всем разобраться Вам труда не составит.

Підтримую: у нас (в ДНУ) були і операційні підсилювачі, і мікроконтролери, і осцилографами міряли сигнали, і криптографія, і цифрова обробки сигналів, і багато чого іншого. Звісно, якісь викладання була посередньою і був значний відрив між теорією та практикою. Але основам вчать. Головне — хотіти вчитися.

Конечно. Вопрос только в том, стоит ли отбывать 4-6 лет в ВУЗе для того, чтобы получить знания, которые можно выучить за 1-2 года самостоятельно?

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

Если мы говорим о ВУЗах типа MIT, Harvard, Stanford.. и IT, я соглашусь. Но вряд ли сюда попадет хоть один украинский.
1. Нужная систематизация вообще не гарантирована в ВУЗе. К тому же можно найти другие источники. В том числе программу мировых топ-вузов.
2. Единомышленников и специалистов лучше искать на форумах, митапах и т.д. В ВУЗе очень много случайных людей, которые просто отбывают и будут только отвлекать. Много преподавателей банально не имеют достаточной квалификации.

К тому же, ВУЗ не только профильным предметам учит.

именно, и это огромный, если не главный, недостаток.
Зачем программисту ОБЖ, История Украины, Философия, История культуры, «Дилова украинська мова», Правоведение и прочий бред?
Если тебе это интересно, ты сам начнешь на досуге изучать эти предменты при этом без призмы видения преподавателя или пропаганды. Если нет, выучишь чтобы сдать и забудешь как страшный сон. Все что останется в голове можно будет уместить на 1 странице А4 крупным шрифтом.

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

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

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

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

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

Водить автомобиль и самообороне учат в той же армии

::facepalm

¯ \ _ (ツ) _ / ¯

Так я и не соврал. Куча друзей научились водить именно там.

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

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

Подписаться на комментарии