Вертолет «Индженьюити» на поверхности Марса. Источник фото: бортовая камера на марсоходе «Персеверанс».
10 апреля 2021 года специалисты лаборатории реактивного движения NASA (Jet Propulsion Laboratory, JPL) сообщили, что во время теста лопастей марсианского вертолета «Индженьюити» на высоких оборотах произошла нештатная ситуация. Аппарат не пострадал, вероятно возникли неполадки в аппаратном и программном обеспечении. НАСА обрабатывает полученные данные телеметрии и уже перенесло дату первого полета вертолета на 14 апреля или позже, в зависимости от решения текущей проблемы и дополнительных тестов.
НАСА уточнило, что во время последнего теста последовательность команд, управляющая элементами теста, завершилась досрочно из-за истечения сторожевого таймера (“watchdog” timer expiration). Это произошло, когда вертолет самостоятельно пытался перевести режим работы бортового компьютера из «Предполетного» в «Полетный». Специалисты JPL проверили и подтвердили, что сейчас вертолет прекратил процесс тестирования, находится в безопасном состоянии и внешне не пострадал. Он передал в ЦУП на Землю все необходимые телеметрические данные.
Аппаратный сторожевой таймер контролирует последовательность выполнения команд и предупреждает систему о любых потенциальных проблемах. В данном случае он помог системе вертолета оставаться в безопасности, не дал продолжить работать в нештатном режиме и предотвратил поломку устройства.
Специалисты JPL сейчас проверяют телеметрию, чтобы диагностировать и понять проблему. После этого они проведут еще один тест работы лопастей на высоких оборотах (~2400 об/мин).
Ранее НАСА планировало, что первый автономный полет марсианского вертолета на три метра вверх с зависанием должен был состояться вечером 11 апреля. Теперь он перенесен на еще минимум на три дня — до 14 апреля или позже.
Марсоход «Персеверанс» находится на удалении 65 метров, его бортовые камеры внимательно следят за вертолетом «Индженьюити».
«Марс труден не только тогда, когда вы приземляетесь, но и когда вы пытаетесь оторваться от него и летать вокруг над планетой», — пояснила руководитель проекта «Индженьюити» МиМи Аунг (MiMi Aung). О том, какие трудности возникли при реализации этого проекта, можно почитать в этой публикации на Хабре.
Вертолет «Индженьюити» имеет массу 1,8 кг, четыре опоры с посадочными чашками, на его борту установлены две цветные камеры (0,5 МП для ориентации и 13 МП для аэрофотосъемки в 4K), система навигации, включая лазерный высотомер от SparkFun Electronics и гиростабилизатор (IMU), система передачи данных (канал связи до 250 Кбит/с на расстоянии до 800 метров от марсохода), а также аккумуляторные батареи и солнечная панель. На дроне установлены два соосных несущих контрвращающихся карбоновых винта диаметром 1,2 метра каждый, их обороты будут достигать 2 537 в минуту. Заряда батарей должно хватать на один полутораминутный полет, на который в среднем затратится 350 Вт мощности.
Аппаратные системы «Индженьюити» основаны на плате SoC Snapdragon 801. В нем установлен Linux и открытое ПО. Вертолет будет летать самостоятельно, без участия оператора. Он должен взлетать, делать несколько маневров и приземляться, ориентируясь на местности автономно, задействуя лишь минимум команд с Земли, отправленных заранее.
Заявленное НАСА время автономной работы дрона на поверхности Марса — 30 солов (31 земные сутки). За это время он должен подготовить свои бортовые системы, совершить первый тестовый полет, состоящий из тридцатисекундного подъема на три метра, а также четыре-пять запланированных полетов на дальние расстояния, в которых он будет подниматься на высоту до 5 метров и отлетать от марсохода на расстояние до 100 метров. Фактически пятая часть этого времени уже прошла, а вертолет еще не взлетел даже один раз. Вероятно, что количество его полетов НАСА сократит из-за деградации батарей и проблем с незащищенной аппаратной частью, которая не сможет работать дольше расчетного срока.
Цель использования первого БПЛА на Марсе — разведка, исследование труднодоступных мест и сбор данных для создания более совершенных дронов, способных работать в разреженной атмосфере планеты в будущем.
4 апреля вертолет «Индженьюити» в штатном режиме отделился от марсохода и десантировался с высоты 10 см от его брюха на поверхность планеты.
5 апреля НАСА сообщило, что вертолет успешно пережил первую марсианскую ночь в автономном режиме. Его бортовые системы выдержали внешнюю температуру около -90°C. Сейчас вертолет самостоятельно заряжает свои батареи и готовится к первому полету.
7 апреля 2021 года НАСА опубликовало селфи марсохода «Персеверанс» вертолетом «Индженьюити». Тогда же стало известно, что вертолет впервые в тестовом режиме совершил вращение лопастями на Марсе.
9 апреля 2021 года «Индженьюити» успешно разблокировал роторы двигателей и протестировал запуск лопастей на низких оборотах.
Вертолет «Индженьюити» проверил работу лопастей на скорости 50 оборотов в минуту.
Богатый язык инженера - это ещё один способ утвердить свой профессиональный уровень в глазах окружающих.
- Ооо, ты инженер конструктор?
- Да!
- Скажи что-нибудь как инженер конструктор!
-Крыльчатка насоса.
- Бог с ним, отправляй, по замечаниям исправим...
Профессия «Инженер» - компактное название с громоздким синтаксисом и семантикой. Благодаря труду инженеров страны развиваются, а население выходит на новый уровень жизни. Каждый из нас хоть раз восторгался видом чего-то нового – например, ракеты или новой машины. Мы путешествуем в разные страны, в том числе, с целью посмотреть на технические выставки и развитие стран, то есть, на работу инженеров. Однако за каждым открытием и творением стоит ни с чем не сравнимый труд. И в каждом открытии и творении стоит инженерная мысль, возможно, уникальный проект инженера.
И в каждом открытии и творении стоит инженерная мысль, возможно, уникальный проект инженера.
Сейчас, в 21 веке, особенно после пандемии и переживаемого экономического мирового кризиса, очевидно то, что надо либо иметь стабильную зарплату в крупной фирме, желательно государственной (с фиксированным окладом), либо уходить в свободное плавание и закладывать почву для другой жизни с желаемым уровнем дохода. Для этого надо составить и проанализировать сводку подводных камней, поджидающих тебя на пути к свободе и воплощению своих амбиций.
В данной статье рассмотрим проблемы фриланса на примере профессии – «Инженер – проектировщик в машиностроении». На протяжении всей истории человечества изобретателей «недооценивали». Ничего не изменилось и сейчас: на полках патентных бюро пылятся миллионы чертежей, которые еженедельно пополняются новыми и новыми диковинками. Изобретатель обычно может рассчитывать на очень скромное вознаграждение за свой труд: даже если его идею берут в работу, авторские отчисления, как правило, весьма невелики.
Причина в том, что настоящее изобретение состоит из двух частей — технической части и бизнес-части, причём смастерить бизнес-часть обычно значительно сложнее. Изобретатели, которые выполняют работу целиком, выстраивая собственными руками конвейер по производству собственных изобретений, получают от общества щедрое вознаграждение за свои труды. Так, к примеру, если бы Генри Форд жил в наше время, он имел бы состояние в 200 млрд долларов и был бы богатейшим человеком планеты, создание своего конвейера с исследовательским опытным бюро и производством это отдельная тема.
Так, к примеру, если бы Генри Форд жил в наше время, он имел бы состояние в 200 млрд долларов и был бы богатейшим человеком планеты.
Выделю проблемы, поджидающие проектировщика после закрытия дверей работы на дядю/тетю, и сразу пути их решения как на деле, так и в своей прекрасной головушке:
Создание проекта с подробным описанием задачи
Создание проекта с подробным описанием задачи
Итак, подстава № 1
Все зависит от полноты и качества информации на начальной стадии – ТЗ. Во избежание переделок старайся навязать заказчику начало сроков проектирования только после утверждения эскизной проработки всех узлов устройства. Если заказчик даже немного адекватен, то идет навстречу, потому что тоже не хочет, чтобы вертикальный виброконтейнер с эксцентриковым электрическим приводом оказался с гидравлическим или вообще без привода=)) Так что на 1-м этапе чаще всего идет подбор вариантов компоновки и подбора комплектующих. И тут, как правило, становится ясно, что же хочет заказчик проекта. Ведь он "всегда прав". Главного конструктора, который должен постоянно держать руку на пульсе проекта и сам увязывать все дополнительные пожелания у тебя нет, поэтому требуй качественное ТЗ.
Несерьезность, студенчество, подработка;
Несерьезность, студенчество, подработка
Подстава № 2
Конечно, сначала ты счастлив, что ушел «в комнату психологической разгрузки», то бишь, к себе домой, но потом у тебя могут возникнуть разные чувства, не самые приятные, и вопросы к себе – не самые простые и понятные.
Может показаться, что занимаешься ерундой, что это не серьезно – брать «заказики», сидя и диване и потягивая чаек, где так спокойно и уютно, никто не доканывает, не маячит перед глазами и не создает чувство важности и ответственности. В таком случае, я предлагаю вспомнить, ради чего ты все это затеял и ушел в «сенсорную комнату» под сладким названием «Фриланс», обозначить еще раз плюсы лично для себя, научиться быть ответственным перед собой, и побыть морем – поволноваться и успокоиться.
Наличие привлекательного портфолио с результатами сложных расчётов, проектирования, фото.
Подстава № 3
Если у тебя пока нет портфолио, то это может быть похоже на неуважение как к себе, так и к потенциальным клиентам, может показаться, что ты даже (О, Боже) перекупщик. Конечно, в наше время реклама занимает чуть ли не первую ступень в становлении успешной личности, поэтому продумай заранее, как и какое портфолио тебе подготовить. Можешь даже вспомнить раздел из производственной эстетики и подобрать разные цвета к фону твоих работ.
Оплата больничных;
Оплата больничных
Подстава № 4
Тут, конечно, тебе надо будет рассчитывать полностью на себя, всегда оставляй в запасе деньги на лекарства, такси до круглосуточной аптеки, на врача, а также обязательно бери аванс. Иначе есть вероятность повреждения твоего «поверхностного слоя» под воздействием инструмента – жизни…, а деформационное упрочнение в виде финансовой «подушки» повысит износостойкость и усталостную прочность…ну да ладно, ты все уже понял.
Когда заказчик - начальник, а ты хотел от этого уйти;
Подстава № 5
Тут лучше выбрать позицию сотрудничества на равных условиях, и начать следует с головы. Дай себе установку, что ты и заказчик работаете на равных условиях, не идете на компромиссы, не наступаете себе на тапки, а сотрудничаете. Ты же помнишь, что эффективность применения станков с ЧПУ ВОЗРАСТАЕТ при повышении точности, наличии сложных условий обработки, при необходимости перемещения детали и инструмента в пяти-шести координатах и т.д.? Вот и старайся не отходить от четких переговоров по делу с заказчиком и не бойся задавать много сложных вопросов, чтобы видеть проект со всех сторон! Вы – коллеги, и никаких пирамид. Поверь, от этого будет комфортно вам обоим.
Нет постоянной загруженности и стабильных денег;
Подстава № 6
Нет постоянной загруженности и стабильных денег
Быстрее, выше, сильнее. В империю нарциссизма надо до смерти хотеть все успеть, охватить, стать лучшей версией себя, выйти из зоны комфорта (хотя это термин был придуман для бизнеса изначально). Тут может получиться, что пропадет мотивация, если ты заметишь себя за 8-м часом черчения проекта стоимостью 700 рублей, например. Выдохни! Этот заказ может быть таким, но это вовсе не значит, что все заказы одинаковые. И с этой прекрасной мыслью повысь износостойкость своей нервной системы - забей на все, выпей чаю, дочерти, и верь в следующий заказ. Желательно верить сильно, а то захочется вернуться на работу, позабыв, как все начиналось.
Общение с коллегами;
Общение с коллегами
Подстава № 7
Сначала ты радуешься, что избавился от токсичной коллеги, скучаешь по остальным прекрасным товарищам, а затем ты просто скучаешь по всем, даже по токсичности коллеги, по эмоциям. Хоть каким-то. Да, энергообмен с людьми важен, поэтому общайся на форумах, ходи на тематические выставки, вебинары, общайся с друзьями, выходи из комнаты.
Придётся постоянно развиваться в направлениях, о которых ты возможно раньше и не задумывался (либо не хотел задумываться): продажи, маркетинг, бухгалтерия, стратегия и тактика ведения переговоров, сильное имя и многое другое.
Подстава № 8
Не, ну это подстава, конечно, ну, а как ты хотел? Век живи – век учись. Тут придется похлопотать над прокачиванием себя в этих областях, хотя бы до уровня новичка-любителя, чтобы не платить таким же фрилансерам за помощь. Ролики на youtube, вебинары, семинары – все в открытом доступе, понятно, читабельно, разжевано. Дерзай, это не трудно, въедешь, что по чем, и будет легко.
Инженерный фриланс в СНГ развит очень слабо, поскольку инженерная деятельность, как правило, очень сильно привязана к конкретному производству.
Подстава № 9
Есть такое, но это не проблема века. Все в твоих руках. В помощь Peopleperhour, Профессионалы ru, weblancer net, Linkedin, Яндекс Услуги , а также твои знакомства. Вспомни метод неполной взаимозаменяемости, где требуемая точность замыкающего звена размерной цепи достигается некоторым заранее установленным риском путем включения в нее составляющих звеньев без выбора, подбора или изменения их значений. Размещай резюме везде ыыыы!! Где-то точно «выстрелит».
В регионах нужно ИМЯ
Подстава № 10 или «опытные дядьки»
Если ты живешь в мегаполисе, то тебе будет проще найти заказ, а если в провинции, то там, конечно, желательно иметь уже имя, гремящее на всю округу, что только ты и только к тебе. Тут всегда нужно помнить, что так будет только поначалу, это состояние надо пережить, а еще «старые матерые волки» не будут браться за курсовые студентов, дипломные проекты и другие альтернативные «несерьезные» заказы, где ты всегда «за».
Тайм менеджмент
А это вот не подстава, а крутая тема.
Советую узнать побольше об этом, чтобы научиться самоорганизации, «не кусая» себя за посещаемую музу - прокрастинацию. Составляй списки дел на сегодня, и не только по заказам, а лучше планируй свой день на три дня вперед по часам, заведи блокнот или приложение на смартфоне, чтобы жить по графику. Сначала будет напрягать, потом спасибо скажешь.
Будь в меру жестким, в меру податливым, но особо не деформируйся под воздействием внешних сил! Будь собой! Каждый, кто по-прежнему считает, что хорошо там, где нас нет, все вышеупомянутое не пугает, а воодушевляет, манит чертежами и моделированием изобретений под солнцем и пальмами на Бали, а трудности с первым заработком в первые несколько месяцев мотивируют, то жду всех с вопросами, предложениями и комментариями!
CJ Pierce (Drowning Pool), Wes Borland (Limp Bizkit), Jame Shaffer (Korn), ну и я с педальками
Привет, Хабра!
Сегодня одолела ностальгия и хочу рассказать, как делал устройства для музыкантов — педальки-контроллеры, наделяющие музыкальный процессор Digitech Whammy новыми возможностями. Устройства мало кому нужны, но кому нужны — то позарез)
Этот проект мне очень дорог, потому что с него началась настоящая страсть к созданию чего-то нового. И хоть я давно уже не брался за паяльник, а основное время посвящаю развитию в управлении продуктом, всё ещё не оставляю фантазии о фееричном возвращении в music hardware, которое сделает немного шума в чахнущем царстве рока.
Да и перед именитыми ребятами (на фото, например, CJ Pierce из Drowning Pool, James "Munky" Shaffer из Korn и Wesley Borland из Limp Bizkit, ну и я с девайсами), признаться, стыдно, что пропал на целых несколько лет — ни слуха от меня, ни духа о новых устройствах.
Удачно сложилось, что сегодня же есть 3,5 часа в самолёте, так что настало время офигительных историй — расскажу, как появились эти железки реально из мусора. Курьёзы и неудачи, какие устройства хотел и что получилось, как они оказались у топ-музыкантов мира и почему я отложил такие крутые штуки в долгий ящик.
Возможно это смотивирует кого-то вернуться и доделать свои идеи, а кому-то просто поднимет настроение. Итак, вперёд! Точнее назад, в 2010 год...
Педаль с Марио
Год 2010 был жутко насыщенным (как, впрочем, и все остальные), потому что я работал параллельно:
а) Продавцом в музыкальном магазине,
б) Администратором в концертном агентстве,
в) Был владельцем двух репетиционных баз и совладельцем магазина игрушек,
д) Играл рок с бандой за какие-то деньги и так далее.
В один из выходных, проснувшись в Музторге, мой коллега Кузьмич показал видео на YouTube диковинной и взрывающей голову педальки от Molten Voltage. Это был midi-контроллер для Digitech Whammy, который превращал питч-шифтер в арпеджиатор.
Стоила педаль 100$ (3 000₽ по тем временам) и платить такие бешеные деньги за девайс было большим расточительством. А так как я увлекался программированием микроконтроллеров (и даже сделал подсветку днища для друзей, звёздное небо для клуба "Шоколад" и другие кринжовые штуки из 2007-ого), то сходу предложил за трёху сделать педаль сильно лучше.
Мне до сих пор плохо верится, что это сработало. Зацените стойки для платы, напиленные из шариковой ручки. Крутилка от выброшенного осциллографа, покрашенная цапон-лаком и отполированная пастой ГОИ. Ну и так далее
Папа у меня инженер и с детства дома были кучи радиодеталей и плат, а я паял всякие нехитрые приспособления. Из Музторга была позаимствована Digitech Whammy, в радиомагазине куплен PIC16F628, собрана схема чисто из советских деталей, написана программа на ассемблере — и готово. На всё про всё пара месяцев работы по вечерам.
Получилась такая штука. Это уже мелкосерийный образец — ручка справа заводская
Всё делалось дома вручную. Сложнее всего было напилить квадратные отверстия для разъёма питания и окошко для цифры. Окошко с внутренней стороны было закрыто приклеенным куском прозрачной шайбы, которая всегда была на шпинделе компакт-дисков, помните такую?
Программная часть вообще без каких-то новшеств. Пресеты в EEPROM, на старте читаем активный, загружаем в RAM. Раз в несколько миллисекунд опрашиваем кнопки и рисуем на экране чиселку. Конечный автомат прямо в прерывании таймера за микросекунды делает всю работу + считает темп для функции Tap Tempo (которая, конечно, подвирала).
Описываю так подробно, чтобы вы оценили масштаб дальнейшего изумления. Да, с точки зрения функциональности штука получилась более продвинутая, чем у заморского аналога. Но как она была сделана, бог мой, резисторы млт, конденсаторы из китайских приёмников, на первых педальках ножные кнопки были самоделкой из советских микропереключателей, ну и платы, конечно, сфабрикованные утюгом из позаимстованного со столешницы стола текстолита.
Сразу было сделано 3 таких педали — двум друзьям и себе. Мне девайс не понравился – не считал темп в bpm, плохие возможности программирования, мало программ, работал только с одним типом Whammy. Тем не менее, я снял видео и тоже залил в YouTube — типа зацени, Молтон Вольтейдж, пацаны с лебедевочки тоже могут!
На видео добавляет стиля миди-шнурок, свитый из трёх отдельных проводов, советские аудио-разъёмы DIN-5, демо-версия видео-редактора и порванный носок. Да, тогда YouTube многое прощал.
Так вот, какое было удивление, когда мне начали писать люди из разных стран с просьбами продать им такое же чудо-устройство. Я сделал ещё пару штук. Потом ещё. Потом ещё и понял, что надо что-то менять, потому что тратил на сборку слишком много усилий и хватит это терпеть. Поднял цену (аж на 300 рублей) и заказал платы, потому что ну достало их шлёпать утюгом.
Здесь уже фирмища — платы заводские, с защитной зелёнкой. Работали, как автомат Калашникова
Но само устройство мне всё ещё не нравилось. Слишком много инженерных и конструктивных недостатков. И функциональности маловато — хотелось больше, ярче, веселее.
Тем не менее до 2013-ого года они продавались именно в таком виде. Начали подтягиваться ребята с именами — одна ушла Паше Додонову в Дельфин. Одну подарил Стиву Ваю, когда он приезжал в Новосибирск, но он ей скорее всего максимум ножку стола подпирает. Зато поиграли с ним на гитарах, он и его менеджер Франко Пеона похвалили мой Гибсон Лес Пол, ух хороший вечерок был. Но не об этом.
Это Рома на концерте, но видна уже новая педалька — чёрная
Ещё одна ушла Роме Хомутскому в 7Расу. А я стал задумываться, что пора бы сделать следующую версию — на порядок круче и для этого нужно подтянуть технологии и инструментарий. И в следующий раз, когда 7Раса поехала в тур в Сибирь, купил в Москве на Авито макбук, чтобы учиться на нём работать и впитывать магию Эпол. Попросил ребят привезти мне его заодно в Новосиб — типа, всё равно ж сюда едете. Вот такая звёздная доставка получилась.
Главные ошибки
В моей жизни тоже происходили изменения — начали расти волосы в странных местах стал больше кататься с артистами, выполняя функции менеджера на шоу. Своих же концертов, наоборот, стало меньше и в голове начали появляться мысли про занятие в будущем, а не про то как здорово мы вчера качнули тысячник и какой удался бодрый стейдж дайвинг.
Запущенные мамкины бизнесы не приносили удовольствия, а продажи коробочек с Марио, наоборот, подогревали мысль о том, что можно производить устройства, продавать их и в ус не дуть.
Мне безумно приятно было получать сообщения, как слева. А справа — типичный вид педальки первой версии, которые отправлялись к клиентам
Но педальки продавались редко, и я придумал, что если их улучшить, то получится ну совсем бомба и станут они разлетаться как горячие пироги. Да, на этом месте можно начать загибать пальцы, подсчитывая допущенные грандиозные ошибки. Но мне за них не стыдно — тогда я понятия не имел, что такое IT, как делать продукт, чем бэкенд отличается от фронтенда, а главным инструментом программирования был паяльник. Мне просто хотелось делать и продавать уникальные штуки и я делал и продавал.
Итак, краткий список принципиальных улучшений был намечен такой:
— сделать точнейшую поддержку темпа в bpm. Мы же говорим про арпеджио, значит надо чтобы эффект точно попадали в контекст трека;
— поддержать все типы актульных тогда (да и сейчас) Digitech Whammy, а их 4 штуки;
— сделать овер-дофига пресетов и чтобы их было легко программировать, как на самой педальке, так и на компьютере;
— сделать полную поддержку MIDI, чтобы педаль встраивалась в цепочки других устройств, синхронизировалась по темпу, могла сама управлять темпом других устройств и т.д.
— работать устройство должно от любого блока питания и от батарейки и ещё и контролировать её разряд, ну и так далее.
Было ещё много других хотелок, но даже эти уже слабо ассоциировалось с резисторами млт и стойками из шариковых ручек. Ещё тогда вышел iPhone 4 и мне, конечно же, хотелось делать продукты в стиле Apple — чтобы они были офигенные и на голову опережали конкурентов по желанию ими обладать. В общем, наметился переход на более продвинутую технологию, как в hardware, так и в software.
Оказалось, что делать такие платки в домашних условиях нет большой сложности
С железом определился легко. Это точно должна быть 2-ух сторонняя плата и smd монтаж, чтобы получить максимум от домашнего прототипирования плат утюгом. Дальше купил паяльную станцию с феном, сделал несколько плат и обнаружил, что 0805 это раз плюнуть, довольно легко запаиваю 0603, а вот 0402 уже тяжко.
С процессором чуть сложнее. Я остался на микроконтроллерах PIC, потому что к тому времени начал мыслить их ассемблером, и он меня полностью устраивал — в голове просчитывал нужное количество тиков в прерываниях, чтобы получить real time точность и т.д. Но сам камень итеративно менял несколько раз, потому что раздувались хотелки и в итоге пришёл к PIC16F1939 в корпусе TQFP. Почти что максимум, что мог предложить Microchip на 8-bit архитектуре.
Это я купил фотоаппарат, чтобы записывать качественное видео и сфотал партию процессоров и винтики для верхней крышки, на поиски которых потратил немало времени, но они просто ахрененные
Но самое сложное оказалось с software. Я несколько недель маялся и принципиально не мог придумать, как мне сделать так, чтобы все задуманные функции выполнялись параллельно, контролируемо и точно. Напомню, я не был программистом. Я был рокером.
Здесь нужно сделать лирическое отступление про образ жизни. Тогда я сдружился с моим лучшим другом Славой, очень известным в узких кругах CG. Слава как-то решил, что хочет делать 3D-мультики ну хотя бы на уровне Pixar и начал делать. Мы с ним быстро опознали друг в друге упоротых людей и сблизились настолько, что я постоянно жил у Славы. Днём в основном мы мотались по делам, а ночи напролёт дули кофе и пилили проекты. Кстати, какой-то мультик не без помощи Pixar мы в итоге сделали, но это совсем другая история)
Позже мы реально делали мульт. Собирали аниматик, строили рендер-ферму, но об этом как-нибудь в другой раз
В итоге как-то поздно вечером я вернулся домой и папа мне подсунул статью из технического журнала. Он знал, что я чёто-то там делаю с микроконтроллерами и время от времени подкидывал интересные, на его взгляд, материалы.
И какого было изумление, когда я понял, что в статье описывается решение моей боли — а именно, как в операционной системе работает планировщик задач. Я был ослеплён изящностью и красотой этой идеи, и тут же сел писать демку планировщика. Часам к 4-ём ночи она была готова, я не думая прыгнул в машину и прикатил к Славе, нашёл его сидящим с краснющими глазами за мониторами и, сбиваясь, в эйфории рассказал про случившийся прорыв. Слава выслушал, посмотрел оценивающе и сказал: "Иди спать, педрила". Так появилось гордое название PeOS в пунктах преимуществ устройства и Pe — это не pedal.
Конечно, это было только начало пути, а дальше наступил сезон гастролей и я параллельно начал зачитываться как детективом "Операционными системами" Танненбаума и писать свой менеджер задач — core, вокруг которого строилась вся система.
Почему не взял готовый? Да тупой потому что. Даже Git не знал зачем нужен. Ну и хотелось во всём разобраться, сделать идеальный девайс.
Хорошо запомнил ощущение сюра, как в Томске Борис Гребенщиков с Аквариумом изрядно накидались в гостинице, плясали на столах, а я в центре этой вахканалии пишу на ассемблере свою операционную систему.
Как вам такое? Самый жёсткий был модуль экрана — со всеми шрифтами и анимациями там около 7 тысяч строк
Выбор ассемблера привёл к понятной проблеме. Вы видели когда-нибудь абсолютно нечитаемый код? Скорее всего вы видели эталон достижений в области программирования по сравнению с тем, что стало результатом работы. 30+ килобайт ассемблерного кода — это очень много.
Но дальше сюр будет только крепчать.
Прототипы
Начало работы полностью происходило в симуляторе, но довольно скоро дошло время и до проектирования схемотехники. Схему для первой версии педали чертил в простейшем Sprint Layout. Для второй же версии потребовался инструмент серьёзнее — изучил Eagle и разводил платы там.
Мне хотелось странных решений — обойтись без кнопки включения, но чтобы педаль могла выключаться с батарейкой внутри. Сделать хитрую схему питания, протестировать возможности разных копеечных экранов от телефонов, сделать автоматической определение педали по (однонаправленному, на секундочку) протоколу MIDI и т.д.
Слева россыпь прототипов, а справа финальный в демо-корпусе
Прототипов было с десяток. Сначала неказистые макеты частей системы, потом начал объединять их на одной плате с прицелом засовывания в корпус. Но даже таких было штук 5 или 6 перед финальной версией.
В итоге устал от того, что провода постоянно рассыпаются и отваливаются и придумал для прототипов макет-корпус из орг-стекла, который и стал уже полноценным прототипом педали. Он постепенно обрастал функциональностью, тестировался в разных условиях без риска повреждения кишков.
Ручной работы с корпусами, да и со всей педалью прям хватало. Но мне реально нравилась каждая педаль, которая в итоге выходила за пределы моей комнаты
Производство корпусов на этот раз было не полностью ручным. Вручную пилил только круглые дырки на боках. Для верхней панели сделал чертёж и отдавал на гидроабразивную резку. Дальше заказывал наклейки и сверху накрывал оргстеклом, тоже вырезанным по чертежу.
Это разная графика на разных экранах. Логотип я потом переделал на более строгий. Но больше всего меня прикалывала иконка ноги, которая символизировала шаг. Прикольно)
UI весь нарисовал сам. А потом перерисовал. Тогда мы со Славой время от времени нехило рубились в танки, по-этому в педальке все цифры стали трафаретными, как будто с военной техники.
Для соединения педали с компьютером разобрался с Objective-C и написал программу (о, боги, как-то я заглянул в код и чуть не заплакал кровью) под Mac OS. Помню, как у меня бомбило, когда узнал, что в Objective-C есть специальный объект NSNumber для числа. Я привык в 1 байт упаковывать 4-битное число и 4 буля и мне это показалось кощунственным разбазариванием ресурсов.
Несколько дней потратил на написание пресетов и сочинения демок для каждого из пресетов. Записал с ними видео уже без порванного носка и смонтировал в iMovie. Но и там есть смешной факт — левый кроссовок, которым я давлю на кнопки (чтобы не было носков в кадре) — у меня был в единственном экземпляре. Правый я порвал практически сразу на футбольном сражении, по-этому кроссовок был чистый и презентабельный — ещё не успел его сносить.
Было ещё несколько ударов судьбы, которые чуть не валили уверенность в блестящем будущем проекта с ног. Точно помню два.
USART Педалька должна была встраиваться в MIDI-цепочку. MIDI — это последовательный однонаправленный протокол с токовой петлёй на физическом уровне. Мне нужен был 1 MIDI-вход для получения данных извне, 1 MIDI-выход для отправки данных вовне и 1 MIDI-выход для отправки данных в процессор Whammy, собственно для прямой функции девайса, ради чего затевался сыр-бор.
Я был абсолютно и непоколебимо уверен, что USART-ов в PIC16F1939 ну минимум 2 или 3, а оказалось, что ОН ОДИН. Это случилось, когда почти вся функциональность была закончена и более-менее протестирована, а оставалась только реализация MIDI. Я настолько тогда охренел, что растерялся.
Добавлю контекста — денег тогда было не то чтобы много, а точнее дно было тотальное. И процессоров я уже заказал пару десятков и это было сильным ударом.
В общем, выкрутился ужасно. На выход USART'а добавил переключатель физических выходов MIDI на транзисторе. И в зависимости от назначения байт отправлялся в один или другой выход. По факту предельная скорость передачи данных снизилась в 2 раза, но на практике с этим решением вообще никаких проблем.
Деление на 3 Когда мы говорим про синхронизацию темпа с другими источниками, то нужно уметь очень быстро подстраивать темп под генератор синхроимпульсов — примерно сотню раз в секунду. И вообще задача это не сильно сложная, но в музыке есть триоли — то есть 3 ноты за долю.
В итоге задача свелась к делению 16-ричного числа на 3. А дешёвый 8-битный контроллер не то чтобы вообще умел это делать. Как бы там есть сложение, вычитание и сдвиг, которым можно делать умножение и деление на степень двойки. Но не другого числа.
И опять бессонные ночи в попытках решения задачи за прогнозируемые микросекунды. Крутил в голове цифры и так и этак и в итоге придумал алгоритм, которым страшно гордился, пока не узнал, что это какой-то супер-базовый алгоритм, который программисты изучают на 1-ом курсе. Что ж, ну ок.
Релиз
Педаль вышла в свет в 2014-ом. Для релиза первой версии заказал 10 плат у китайцев за 5 долларов. Пришло 11, что безмерно обрадовало. Платы собрал сам и после самодельных плат с трещинами в дорожках и недотравами это был просто глоток свежего воздуха.
Справа изготовление платки, два прототипа разного уровня проработки. Чёрный — уже предсерийный
Цену выставил, как мне тогда казалось, солидную — 5 000₽ за коробочку. Штук шесть у меня купили в первый же день ближайшие знакомые. Ощутил запах победы и что всё не зря. Но дальше продажи полностью остановились. Надо было что-то делать.
Не долго думая, решил использовать способ, сработавший раньше, но с небольшим дополнением. Педаль сфотографировали у знакомого фотографа по-моему за бутылку виски, которая и фигурирует на фотке. Мой друг собрал сайт, который можно посмотреть в веб-архиве. Угадайте, чего не найти на сайте? Правильно, кнопки купить!)
Дальше записал длинное видео с объяснением всех функций, доступных в педальке. Думал показать здесь тот самый видос с разбором всех функций, но лучше добавлю видео ребят, которые встраивали дикие звуки D2 в свою музыку ↑
Залил обе версии на ютюб и... Почти ничего не произошло. Да, заказов стало чуть больше, в среднем по одному-два в неделю, но этого всё равно было мало, чтобы выходить на какой-то конвейер. И для жизни ж ещё деньги зарабатывать как-то надо было.
Звёздный сюр
К этому времени стало уже понятно, что ввязался я в длинную драку и быстрых побед не будет. Идея возникла такая — надо, чтобы топ-музыканты использовали педали в написании музла и после этого уже их фанаты и кореша из тусовки точно начнут заказывать коробочки пачками. Ну и желательно чтобы в новой тогда соц сети инстаграм педальку разместили.
Вообще, тема оказалась в целом рабочей, но мне не хватило опыта и уверенности, чтобы её реализовать в полной мере. Тем не менее, произошли крутые события, которыми я горжусь до сих пор.
Это Уэс на NAMM 2014. Сам я туда, конечно же, не попал, но Уэс здорово мне помог, век не забуду
Hed P.E. Одним из первых во внимание попал Wesley Geer (экс Hed P.E.). Он приезжал в Новосибирск вместе с Korn, оказался супер-общительным чуваком и с ним удалось посидеть в баре. Договорились, что я отправлю ему педаль на NAMM с кем-то из Нск (сам я не могу поехать, бабок не было), так и вышло. До сих пор время от времени переписываемся.
Drowning Pool
Я долго работал в концертной индустрии, плюс мы много играли рок, по-этому, конечно, знал почти всех организаторов, прокатчиков и промоутеров, и попробовал через них рассказывать о своих педальках приезжающим топ-музыкантам.
Так произошло с группой Drowning Pool. Их гитарист CJ Pierce активно использовал Digitech Whammy в музыке и был отличным кандидатом под "моего" артиста. Через знакомых рассказал их менеджеру про педаль, но так я был вообще на мели, не мог педаль подарить. В итоге менеджер купил педальку и мы здорово пообщались с CJ-ем. Я объяснил ему все функции девайса, он офигел и предложил помочь их продавать в Штатах. Я обрадовался, но опять не хватило опыта дожать тему. Мы просто потерялись.
Та самая Вамми
Но из той встречи я вынес неожиданный бонус. Моя педалька — это контроллер для Whammy, который поддерживал 3 вида процессоров. Но своих Whammy у меня тогда не было. И если пятую версию было найти легко, то четвёртую постоянно приходилось одалживать, чтобы проверить новую партию педалей. А у СиДжея тогда в туре сломалась его Whammy IV. Я его не просил, но он просто взял расписался и подарил её мне.
Я так обрадовался, ппц. Починил её дома, аккуратно почистил, чтобы сохранить историческую задроченность и до сих пор тестирую на ней новые девайсы. На фотке в заголовке она на заднем фоне красная. Помните, в самом начале фильма XXX Вин Дизель кидывает в пропасть корвет под песню "Let the body hit the floor"? Ещё такой мем был с попугаем. Кароче это та самая Whammy, которая в их песнях записана.
Наив Уже не помню, как продал педальку Валере Аркадину из Наива и Матрикса. Но это один из российских музыкантов, который очень много экспериментировал с её звуком. Она вошла в песню "На пределе", Валера написал большое произведение на заказ с её использованием, рассказал о ней в журнале In/Out. Кароче, Валера, каждый раз когда ты звонишь, чувствую безумную радость и уважение, но и угрызения совести, что до сих пор не выпустил новых девайсов.
Korn
Дальше узнал, что ещё раз приезжают Korn и попросил Wesley рассказать о педальке Хэду и Манки. Он не обломался и Манки вписал меня в список приглашённых группой гостей в Нск. К сожалению, Хэд тогда свалился с камнями в почках в Красноярске и остался там в больнице, так что не пообщались, но педалек я всё равно подарил две.
Дядьки оказались очень адекватными увлечёнными людьми
Это была очень странная встреча — на стадионе в Нск мы болтали с Манки, подошёл Джонотан Дэвис и восхитился педалью, рассказал про свой второй проект — Killbot. В итоге Манки записал мой номер телефона и email, мы обменялись контактами и я ушёл даже не подозревая, что вообще произошло сейчас.
Crosses и Deftones Как-то на даче я помогал родителям, копал картошку, и пошёл посидеть в тенёк, потому что припекало. На телефоне высветилось новое письмо — заказ с сайта. Имя заказчика Shaun Lopez. "Что за латинос?" — подумал я.
У меня тогда вообще игра была такая — когда приходил заказ, особенно из-за границы, всегда внимательно изучал, что там за группа, что играют, насколько интересные ребята.
Слева — моя реальность в тот день, когда Шон купил педаль. А справа она у него среди другого хлама
Так произошло и в тот раз. Но уже через несколько секунд я чуть не навалил в штаны, потому что Шон оказался продюсером Deftones, другом Чино Морено и музыкантом в one-man проекте Crosses. Ну а мы тогда сильно фанатели по Deftones.
Я предложил ему 50% скидку за упоминание Smirnov Electronics на его сайте и традиционную фотку в инстаграм. Собственно, Шон без возражений выполнил свою часть обязательств.
Limp Bizkit С лимпами была история прям по касательной. Вес на самом деле Wes не использует Whammy в Limp Bizkit и вообще её не то чтобы любит, но у него есть и другие проекты. Плюс иногда он в инсте разыгрывает всякий ненужный ему хлам.
Уэс и Фред в тот приезд здорово угорели. Мы их свозили в деревню в местный колорит, где Уэс (да, на фото он) снимался в видео с козой и жигой
Тем более, по приезду они показали себя прикольными ребятами типами, которым хотелось лишний раз респектнуть. И то самое, что я мог сделать — подарить свою педальку. Собственно, так и вышло.
Заключение
Было ещё много приключений, связанных и с артистами и с организацией аутсорса производства, и с утратой проектом моего внимания, и как сайт у меня угнали и на нём появились вместо педалей голые китайские тянки. Но полёт заканчивается — мы уже кружим над Новосибирском, по-этому, как минимум, с первой частью закончу.
Как резюме, хочу подчеркнуть — смотрите, как много я совершил ошибок. Собрал почти все: от неверно выбранной технологической платформы до совершенно не организованных продаж и развития, профукал почти все шансы, упустил время. Но главное-то остаётся с нами — музыканты играют на педальках и раз в месяц-два до сих пор ребята интересуются покупкой (безуспешно), как подтверждение, хоть и очень локальной, но ценности.
Так что если у вас в голове есть идеи, но вы не знаете как их сделать, просто делайте. Не думайте, делайте. А как начнёте делать — думайте, и тогда это точно приведёт к какой-нибудь крутой истории.
И если вам было интересно прочитать и интересны другие аспекты проекта, про которые я не успел написать — лайк, шейр, коммент, я с удовольствием отвечу на вопросы, а можт и созрею для второй части статьи.
А если хочется порассматривать другие фотки про девайсы, забегайте в инстаграм, там я время от времени рассказываю о текущих проектах и инсайтах.
Решили заняться с другом созданием мощного заднеприводного багги для езды по грунтовой дороге. Для себя определили, что разгон должен быть около 5 секунд до 100 км в час. В идеале выйти из 5 секунд. Строить по классической схеме, где сердце багги - это двигатель от ВАЗ нам показалось неинтересным. Долго думали, чтобы такое придумать и идея пришла сама собой. В свое время мы ездили с ним в Японию и уже там на выставках познакомились с входящими тогда в популярность электромобилями.
электромотор nissan leaf
За основу Багги мы взяли электрический бесколлекторный мотор от Nissan. Его изюминкой является большой крутящий момент порядка 280нМ с самого начала оборота. Так как багги электрический, а нынче тренд ко всему электрическому добавлять "e", то и наш проект мы назвали еБагги.
В японском электрокаре установлен синхронный трехфазный электромотор мощностью 80 киловатт (109 л.с.) при 2730-9800 оборотов в минуту. Двигатель Nissan Leaf дает крутящий момент 280 Н·м. Паспортный разгон до 100 км/ч составляет 11,9 с. , а максимальная скорость авто равна 145 км/ч. При весе автомобиля значительно превышающим вес нашего багги. График
багги сравнение мощности и крутящего момента от оборотов двигателя
По графику сразу видно, что диапазон работы оборотов двигателя гораздо выше, чем у 1.6 литрового атмосферного собрата. В электромоторе от 0-10500 оборотов. У атмосферника 900-6500. Во вторых полка момента в 280 Нм доступна сразу с 0 оборотов и вплоть до 2700 оборотов и далее идет плавное уменьшение крутящего момента. Связано это с тем, что с ростом оборотов магнитное поле не успевает за скоростью мотора и его влияние на отталкивание ослабевает. Именно поэтому в любом электромобиле типо Теслы, Лифа, да и просто троллейбуса/трамвая Вы чувствуете с самого старта пинок а потом плавное ускорение. А вот пик лошадиных сил доступен не сразу, но зато с 2700 и вплоть до 10 тысяч оборотов. Если посчитать площади крутящего момента и мощности, то они будут не менее в чем в 2 раза превышать площади атмосферного двигателя.
электробатарея Nissan leaf
Один из самых дорогих элементов самодельной электробагги это высоковольтная батарея. Мы брали на разборке одну из самых недорогих. Основная задача это покатушки на даче и в деревне, никаких важных поездок по городу или межгороду не предвиделось. Цена батарейки с 6 делениями остатка емкости порядка 100 тысяч рублей. В нашей батареи остаток чуть более 60%, что с весом багги порядка 850 килограмм позволит кататься в районе 80 км по пересеченной местности. Мы хотели оставить именно родной корпус батареи от Ниссан Лиф. Почему? Во первых он герметичен, что позволит испытывать нашу багги и в водных условиях. Во вторых качество исполнения электроники самой батареи и ее защиты на самом высочайшем уровне. В дальнейшем мы можем экспериментировать, меняя ячейки батареи на более современные. Что позволит или значительно уменьшить массу при той же емкости батареи или увеличить емкость при примерно той же массе.
Каркас делался из металлических труб, которые далее покрывались эпоксидным грунтом и специальной стойкой краской.
подвеска самодельной багги
Основные компоненты подвески было принято решение ставить от Нивы, так как это крайне доступно по наличию и проверено десятилетиями. Исключениями явились кардриджи стоек и задние пружины. Они от VW и Mercedes.
Но недостаточно, чтобы багги заработал, просто взять соединить батарею мотор и педаль воедино. Нужен мозг, который будет этим всем делать управлять. Многие оставляют штатный ниссан, вырезая блок за блоком и часто получая ошибки на самых разных уровнях. Мы пошли дальше, вооружившись устройством для считывания команд CAN шины мы разобрались со всеми блоками, которые нам необходимы. Далее центральный контроллер мы сделали свой. На этапе отладки на ардуино. Далее перейдем на более правильные промышленные решения.
Собрав рулевое управление, нам стало интересно сделать не просто багги, а радиоуправляемую и в дальнейшем автономную машину. Начали копать в сторону работы электромотора усилителя руля. Выяснили, что его принцип рассчитан на работу тензодатчика. Тензометрический датчик (тензодатчик; от лат. tensus — напряжённый) — датчик, преобразующий величину деформации в удобный для измерения сигнал (обычно электрический), основной компонент тензометра (прибора для измерения деформаций). Далее разобрались с командами, которые необходимо присылать на ЭУР в зависимости от скорости движения. Тем самым научились менять усилия ЭУР как нам надо. Изучив тензодатчик поняли его непростое управление и сэмитировали сигналы на ардуино, подключив библиотеки от пульта PS4 PRO.
Кому интересно, проходите по ссылке на этой картинке - она ведет на видео, где подробно рассказываем все этапы. Через неделю расскажем как поставили на колеса и про первые испытания.
Корректность кода на платформе Android является наиважнейшим аспектом в контексте безопасности, стабильности и качества каждого релиза Android. По-прежнему сложнее всего вытравливаются ошибки, связанные с безопасностью памяти и попадающиеся в коде на С и C++. Google вкладывает огромные усилия и ресурсы в обнаружение, устранение багов такого рода, а также в уменьшение вреда от них, старается, чтобы багов в релизы Android проникало как можно меньше. Тем не менее, несмотря на все эти меры, ошибки, связанные с безопасностью памяти, остаются основным источником проблем со стабильностью. На их долю неизменно приходится ~70% наиболее серьезных уязвимостей Android.
Наряду с текущими и планируемыми мероприятиями по улучшению выявления багов, связанных с памятью, Google также наращивает усилия по их предотвращению. Языки, обеспечивающие безопасность памяти – наиболее эффективные и выгодные средства для решения этой задачи. Теперь в рамках проекта Android Open Source Project (AOSP) наряду с языками Java и Kotlin, отличающимися безопасностью памяти, поддерживается и язык Rust, предназначенный для разработки операционной системы как таковой.
Системное программирование
Управляемые языки, в частности, Java и Kotlin, лучше всего подходят для разработки приложений под Android. Эти языки проектировались в расчете на удобство использования, портируемость и безопасность. Среда исполнения Android (ART) управляет памятью так, как указал разработчик. В операционной системе Android широко используется Java, что фактически защищает большие участки платформы Android от багов, связанных с памятью. К сожалению, на низких уровнях ОС Android Java и Kotlin бессильны.
На низких уровнях ОС нужны языки для системного программирования, такие как C, C++ и Rust. При проектировании этих языков приоритет отдавался контролируемости и предсказуемости. Они обеспечивают доступ к низкоуровневым ресурсам системы и железу. Они обходятся минимальными ресурсами, прогнозировать их производительность также сравнительно просто.
При работе с C и C++ разработчик отвечает за управление сроком жизни памяти. К сожалению, при такой работе легко допустить ошибки, особенно при работе со сложными и многопоточными базами кода.
Rust предоставляет гарантии по поводу безопасности памяти, так как использует сочетание проверок во время компиляции, чтобы обеспечить соблюдение времени жизни объектов и владение ими, а также проверки во время исполнения и таким образом гарантировать валидность обращений к памяти. Такая безопасность действительно обеспечивается, а производительность остается не меньшей, чем при работе с C и C++.
Пределы работы в песочнице
Языки C и C++ не дают таких же гарантий безопасности, как Rust, и требуют надежной изоляции. Все процессы Android укладываются в песочницу, и мы придерживаемся правила двух, принимая решение, требуется ли для конкретной функциональности дополнительная изоляция и снижение привилегий. Правило двух формулируется просто: при наличии следующих трех вариантов действий, разработчики вправе выбрать лишь два из них.
В Android это означает, что, если код написан на C/C++ и разбирает потенциально небезопасный ввод, то он должен содержаться в жестко ограниченной песочнице без привилегий. Тогда как следование правилу двух хорошо помогает снижать тяжесть и повышать доступность уязвимостей, связанных с безопасностью, оно сопряжено с некоторыми ограничениями. Работа в песочнице – дорогое удовольствие; для ее обеспечения требуются новые процессы, которые сопряжены с дополнительными накладными расходами и провоцируют задержки, связанные с межпроцессной коммуникацией и дополнительным расходом памяти. Работа в песочнице не позволяет полностью исключить уязвимости в коде, а эффективность такой работы снижается при высокой плотности багов, позволяющей злоумышленникам сцеплять вместе множество уязвимостей сразу.
Язык, обеспечивающий безопасность памяти, такой, как Rust, помогает преодолеть эти ограничения двумя способами:
Снижает плотность багов в нашем коде, тем самым повышая эффективность применяемой песочницы.
Снижает потребность в использовании песочницы, поскольку предоставляет новые возможности, которые более безопасны в работе и одновременно менее требовательны к ресурсам.
Что же насчет всего имеющегося C++?
Разумеется, если мы введем новый язык программирования, это никак не поможет нам с исправлением уже имеющихся багов в имеющемся коде на C/C++.
Вышеприведенный анализ возраста багов, связанных с безопасностью памяти (отсчитывается с момента их появления) позволяет судить, почему команда Android делает акцент на новых разработках, а не на переписывании зрелого кода на C/C++. Большинство багов возникает в новом или недавно измененном коде, причем, возраст около 50% багов составляет менее года.
Некоторых может удивить, что сравнительно старые баги с памятью встречаются так редко, но выяснилось, что старый код как раз не требует экстренного вмешательства. Со временем программные баги выявляются и правятся, поэтому ожидается, что код, который поддерживается, но активно не разрабатывается, со временем полностью очистится от багов. При снижении количества и плотности багов повышается как эффективность работы в песочнице, так и эффективность обнаружения багов.
Ограничения находимости багов
Выявление багов при помощи надежного тестирования, очистки и фаззинга критически важно для повышения качества и корректности любых программ, в том числе, написанных на Rust. Ключевое ограничение, с которым в данном случае сталкиваются наиболее эффективные приемы проверки безопасности памяти – в том, что состояние ошибки должно быть спровоцировано в инструментированном коде, и только так его удастся заметить. Даже в коде, отлично покрытом тестами и фаззингом, множество багов проскальзывает в базу именно потому, что их не удалось спровоцировать.
Каждый из вышеприведенных шагов обходится дорого, а если пропустить хотя бы один из них, то баг останется непропатчен у некоторых или даже у всех пользователей. Что касается сложных базах кода на C/C++, зачастую только считанные специалисты могут разработать и внедрить исправление, причем, даже при затрачивании существенных усилий на исправление багов, внесенные изменения бывают некорректными.
Выявление багов проходит наиболее эффективно, когда баги относительно редки, и есть возможность устранять опасные баги с должной безотлагательностью, в качестве приоритетных задач. Чтобы можно было улучшить выявление багов, нужно в первую очередь предотвратить проникновение новых багов в базу кода.
Предотвращение прежде всего
В Rust модернизируется ряд языковых аспектов, что позволяет улучшить корректность кода:
Безопасность памяти – обеспечивается благодаря сочетанию проверок во время компиляции и во время выполнения.
Конкурентность данных – предотвращает гонку данных. Учитывая, насколько легко при этом становится писать эффективный потокобезопасный код, Rust обрел слоган «Безбоязненная Конкурентность».
Более выразительная система типов – помогает предотвратить логические ошибки при программировании (напр., обертки нового типа, варианты перечислений с содержимым).
Ссылки и переменные по умолчанию являются неизменяемыми – что помогает разработчику следовать безопасному принципу наименьших привилегий. Программист помечает ссылку или переменную как изменяемые, только если в самом деле намерен сделать их таковыми. Притом, что в C++ есть const, эта возможность обычно используется нечасто и несогласованно. Напротив, компилятор Rust помогает избегать случайных аннотаций об изменяемости, так как выдает предупреждения об изменяемых значениях, которые никогда не меняются.
Улучшенная обработка ошибок в стандартных библиотеках – потенциально провальные вызовы обертываются в Result, и поэтому компилятор требует от пользователя проверять возможность провала даже для функций, не возвращающих необходимого значения. Это позволяет защититься от таких багов как уязвимость Rage Against the Cage, возникающая из-за необработанной ошибки. Обеспечивая легкое просачивание ошибок при помощи оператора ? и оптимизируя Result с расчетом на низкие издержки, Rust стимулирует пользователей писать все потенциально провальные функции в одном и том же стиле, благодаря чему все они получают ту же защиту.
Инициализация – требует, чтобы все переменные инициализировались перед началом использования. Исторически сложилось, что неинициализированные уязвимости памяти были в Android причиной 3-5% уязвимостей, связанных с безопасностью. В Android 11, чтобы сгладить эту проблему, стала применяться автоматическая инициализация памяти на C/C++. Однако, инициализация в ноль не всегда безопасна, особенно для таких штук, как возвращаемые значения, и в этой области может стать новым источником неправильной обработки ошибок. Rust требует, чтобы любая переменная перед использованием инициализировалась в полноценный член своего типа. Тем самым избегается проблема непреднамеренной инициализации небезопасного значения. Подобно Clang в C/C++, компилятор Rust знает о требовании инициализации и позволяет избежать потенциальных проблем производительности, связанных с двойной инициализацией.
Более безопасная обработка целых чисел – Очистка во избежание включена в отладочных сборках Rust по умолчанию, что стимулирует программистов указывать wrapping_add, если действительно предполагается допустить переполнение при расчетах, или saturating_add – если не предполагается. Очистка при переполнении в дальнейшем должна быть включена для всех сборок Android. Кроме того, при всех преобразованиях целочисленных типов применяются явные приведения: разработчик не может сделать случайного приведения в процессе вызова функции при присваивании значения переменной или при попытке выполнять арифметические операции с другими типами.
Что дальше
Введение нового языка на платформу Android – серьезное предприятие. Существуют такие связки инструментов и зависимости, которые необходимо поддерживать, тестовая инфраструктура и оснащение, которые потребуется обновить. Также придется дополнительно обучить разработчиков. Это проект не на один год. Следите за обновлениями в блоге Google.
В этом материале я приведу практический пример реализации архитектуры API First с применением спецификации OpenAPI. А именно, сначала расскажу о том, как создал определение API, а затем — о том, как, на основе этого определения, создал серверную и клиентскую части приложения. В процессе работы у меня возникли некоторые сложности, которых я тоже коснусь в этом материале.
Преимущества архитектуры API First
По мере того, как всё сильнее распространяется подход к разработке приложений, основанный на микросервисах, определённую популярность набирает и архитектура API First. У этой архитектуры имеется довольно много сильных сторон.
▍Чёткое определение контрактов
Благодаря применению архитектуры API First можно создавать точные определения контрактов, которые позволяют чётко описывать возможности, которыми должны обладать приложения. Эта архитектура, кроме того, помогает отделять интерфейс системы, предоставляемый внешним пользователям посредством API, от деталей реализации возможностей этой системы.
▍Хорошее документирование API
Применение архитектуры API First способствует тому, что разработчик, создавая API, следует правилам, изложенным в хорошо структурированной, понятной документации. Это помогает тем, кому нужно работать с API, обрести чёткое понимание особенностей интерфейса, который представлен этим API.
▍Создание благоприятных условий для распараллеливания работы над проектами
Это — одна из моих любимых возможностей, получаемых тем, кто применяет архитектуру API First. Если в проекте имеется чёткое описание API, то тот, кто занимается разработкой самого API, и тот, кто пользуется возможностями этого API, могут работать параллельно. В частности, пользователь API, ещё до того, как сам API готов к работе, может, основываясь на уже согласованных контактах, создавать моки и заниматься своей частью работы над проектом.
Теперь, когда мы обсудили сильные стороны архитектуры API First, перейдём к практике.
Практика использования архитектуры API First
Я начал работу с посещения ресурса, дающего доступ к Swagger Editor, и с создания определения моего API. Я, при описании API, пользовался спецификацией OpenAPI 3. Определения API можно создавать и с применением многих других инструментов, но я выбрал именно Swagger Editor из-за того, что у меня есть опыт создания документации для Java-проектов с использованием этого редактора. Swagger Editor мне нравится и из-за того, что он поддерживает контекстно-зависимое автодополнение ввода (Ctrl + Пробел). Эта возможность очень помогла мне при создании определения API.
Правда, я не могу сказать, что свободно владею техникой определения API, поэтому я, описывая свой API, опирался на пример petstore.
Для начала я создал весьма минималистичное определение API, описывающее создание учётной записи пользователя системы с использованием POST-запроса.
Определение API
Генерирование кода
После того, как подготовлено определение API, можно заняться созданием сервера и клиента для этого API. А именно, речь идёт о Spring Boot-приложении. Обычно я создаю такие приложения, пользуясь Spring Initializr. Единственной зависимостью, которую я добавил в проект, стал пакет Spring Web.
После этого я воспользовался Maven-плагином OpenAPI Generator, который позволяет создавать серверный и клиентский код.
▍Генерирование серверного кода
Для того, чтобы на основе определения API создать серверный код, я воспользовался соответствующим Maven-плагином, передав ему файл с описанием API. Так как мы создаём сервер, основанный на Spring, я, настраивая генератор, записал в параметр generatorName значение spring. Благодаря этому генератор будет знать о том, что он может, создавая серверный код, пользоваться классами Spring. Существует немало OpenAPI-генераторов серверного кода, их перечень можно найти здесь. Вот как выглядит конфигурационный файл плагина.
Содержимое конфигурационного файла для генерирования серверного кода
Среди настроек, которые я внёс в этот файл, хочу отметить указание имени пакета, которое будет использоваться при создании классов API и модели. Тут, в общем-то, имеется довольно много настроек, полное описание которых можно найти здесь. В частности, в подобном файле можно задать префикс имён классов модели
Коду, который генерируется плагином, нужны ещё несколько зависимостей, обеспечивающих его успешную компиляцию. Мне удалось найти минимальный набор таких зависимостей:
А теперь — самое интересное: генерирование кода. После выполнения команды mvn clean verify в нашем распоряжении оказываются несколько классов, сгенерированных плагином.
Результат работы генератора серверного кода
В пакете API имеются два основных интерфейса — AccountApi и AccountApiDelegate. Интерфейс AccountApi содержит текущее определение API, оформленное с использованием аннотаций @postmapping. Там же имеется и необходимая документация API, представленная в виде аннотаций Spring Swagger. Классом, реализующим этот интерфейс, является AccountApiController. Он взаимодействует со службой, которой делегирована реализация возможностей, обеспечивающих работу API.
В нашей работе весьма важен интерфейс AccountApiDelegate. Благодаря ему мы можем пользоваться паттерном проектирования «Delegate Service», который позволяет реализовывать процедуры обработки данных и механизмы выполнения неких действий, запускаемые при обращении к API. Именно в коде службы, созданной на основе этого интерфейса, и реализуется бизнес-логика приложения, ответственная за обработку запросов. После того, как будет реализована эта логика, сервер можно признать готовым к обработке запросов.
Теперь сервер готов к работе, а значит — пришло время поговорить о клиенте.
▍Генерирование клиентского кода
Для генерирования клиентского кода я воспользовался тем же плагином, но теперь в параметр generatorName я записал значение java.
Содержимое конфигурационного файла для генерирования клиентского кода
Тут же я, в разделе configOptions, сделал некоторые настройки, в частности, касающиеся библиотеки, на которой должен быть основан REST-клиент. Здесь, для реализации механизма взаимодействия с сервером, я решил использовать библиотеку resttemplate. В разделе configOptions можно использовать и многие другие настройки.
Нам, кроме того, понадобятся дополнительные зависимости:
После того, как код будет сгенерирован, в нашем распоряжении окажутся классы, позволяющие организовать взаимодействие клиента с сервером. Тут же имеются и реализации механизмов базовой аутентификации.
Теперь надо создать экземпляр ApiClient. Он содержит параметры сервера, обмен данными с которым нужно наладить. Затем соответствующие возможности используются в классе AccountApi для выполнения запросов к серверу. Для того чтобы выполнить запрос, достаточно вызвать API-функцию из класса AccountApi.
На этом работа над клиентской частью проекта завершена. Теперь можно проверить совместную работу клиента и сервера.
Проблемы, выявленные в ходе реализации проекта
В последней версии плагина (5.0.1), которой я и пользовался, имеются некоторые проблемы.
При использовании генератора spring для создания контроллера в проект импортируются неиспользуемые зависимости из модуля Spring Data. В результате оказывается, что даже в том случае, если для организации работы соответствующей службы не нужна база данных, в проект, всё равно, попадают зависимости, предназначенные для работы с базами данных. Правда, если в проекте используется база данных, особых проблем вышеописанный недочёт не вызовет. Узнать о том, как продвигается работа по исправлению этой ошибки, можно здесь.
Обычно в разделе определения API components не описывают схемы запросов и ответов. Вместо этого в API используют ссылки на такие схемы, созданные с применением свойства $ref:. Сейчас этот механизм не работает так, как ожидается. Для того чтобы справиться с этой проблемой, можно описать встроенные (inline) схемы для каждого запроса и ответа. Это приводит к тому, что имена в модели генерируются с префиксом Inline*. Подробности об этой проблеме можно почитать здесь.
Если вы применяете более старую версию плагина, а именно — 4.3.1, то знайте о том, что в ней этих проблем нет, работает она хорошо.
В этом репозитории вы можете найти код проекта, который мы обсуждали.
Применяете ли вы в своих проектах архитектуру API First?
На этой неделе Тинькофф брокер устранил серию уязвимостей, которые в совокупности позволяли выводить на счёт карты суммы, в десятки раз превышающие размер депозита.
В этой статье поговорим о некоторых лайфхаках и исправленных уязвимостях, а также попытаемся понять, как устроена маржинальная торговля у Тинькофф брокера.
Вся информация предоставлена исключительно в ознакомительных целях и не является инвестиционной рекомендацией. Автор не несёт ответственности за любой возможный вред, причиненный этим материалом. Уязвимости, позволяющие нанести ущерб брокеру, на момент публикации статьи исправлены.
Основные определения
Торговля в лонг — это ставка на повышение цены. Когда трейдеры хотят заработать прибыль на росте цены актива, они торгуют в лонг.
Торговля в шорт — это ставка на понижение цены. Когда трейдеры хотят получить прибыль за счет снижения стоимости актива, они торгуют в шорт.
Маржинальная торговля
Маржинальная торговля — торговля с использованием заёмных денег, предоставляемых брокером спекулянту в кредит под залог определённой суммы — маржи.
Брокер сам определяет список ликвидных бумаг и ставки риска по ним.
Список ликвидных инструментов у Тинькофф брокера можно посмотреть здесь.
Ставка риска, например, в 20% показывает процент собственных средств в размере позиции.
То есть, если есть сумма 10000₽, то максимальная сумма с учётом заёмных средств, на которую можно купить текущую бумагу будет 10000₽ / 20% = 50000₽.
Также можно сказать, что кредитное плечо по текущей бумаге — 1 : 5.
У Тинькофф брокера ставки риска бумаг по лонговым операциям не меньше, чем по шортовым.
Не баг, а фича: увеличиваем размер шорта в два раза
Данный лайфхак существует уже достаточно долгое время, брокер не спешит его исправлять.
На моем депозите около 3200₽.
Рассмотрим лайфхак на примере акций компании ПИК.
Алгоритм
Покупаем максимальное количество акций в лонг
До покупки
Как можно заметить, на собственные средства я могу купить только 3 бумаги. Ставки риска по бумаге 22.56% в лонг и 25.44% в шорт, что соответствует тому, что с учётом заёмных средств можно купить 14 и продать 12 акций.
После покупки
Пока всё правильно: теперь можно продать 14 своих плюс те же 12 заемных акции. В сумме 26 штук.
Выставляем лимитную заявку на продажу на то количество бумаг, которое доступно продать без учёта плеча. В моём случае это 14 акций. Заявку нужно выставить по цене немного выше текущей. В моём случае цена акции 914₽, я выставил заявку по 915₽.
Система неправильно рассчитала размер плеча для продажи
Как можно заметить, теперь система предлагает выставить заявку ещё на 26 акций.
Выставляем на продажу то количество акций, которое доступно с плечом
После того, как заявки будут исполнены, наши 14 акций продадутся и 26 бумаг пойдут в шорт.
На первом скриншоте видно, что изначально система разрешала нам продать в шорт только 12 акций, но после нехитрых манипуляций мы увеличили размер шорта более чем в два раза, и теперь ставка риска по этой бумаге составляет чуть больше 10%
Если же теперь отменить заявку на продажу 14 акций, то система не разрешит выставить такую заявку снова, нужно проделывать манипуляции заново.
Исправленная уязвимость: как увеличить плечо в десятки раз и «зачислить» заёмные средства на брокерский счёт
Данный кейс я поймал случайно и потом ещё день пытался воспроизвести. Стало интересно, что будет, если выставить две встречные заявки на покупку и продажу по единой цене. Если следовать логике, я должен купить акцию сам у себя, что странно.
Как работает сейчас?
Выставляем заявку на покупку одной акции по 916,4₽ и сразу же пытаемся продать себе по той же цене с плечом 13 акций.
Результат вполне ожидаемый: заявка на продажу 13 акций сервер отклонил:
Как работало раньше?
Рассмотрим тот же кейс: выставляем заявку на покупку одной акции, а также заявку на продажу 13 акций.
В таком случае на моём счету формально было бы минус 13 акций, при этом в портфеле эти акции не отображались бы, а баланс оставался бы неизменным.
Ночью при пересчёте сделок система бы поняла, что на самом деле на биржу заявка не была выведена и отменила бы эти -13 акций.
Но до конца торгового дня система считала, что я нахожусь в шорте на 13 бумаг, поэтому она давала мне более большое плечо по этой акции на покупку в лонг, чтобы я мог покрыть эти 13 акций и купить ещё 14 акций на свои деньги (см. первый скрин).
Итого я в сумме мог бы купить не 14, а 27 акций.
Ночью система снимает «фейковые» -13 акций, но в портфеле остаются все те же настоящие 27 бумаг.
Чтобы было понятно наглядно, покажу некоторые скриншоты, которые остались у меня с тестирований, на момент которого в моем портфеле было 4790$.
Можем видеть, что таким образом получилось купить 2211 акций Vipshop на сумму 62151$. То есть плечо здесь уже более, чем 1 : 12
Размер плеча, в теории, можно было увеличить насколько угодно: если мы выставим заявку на покупку одной акции и по этой же цене продадим ещё 13 акций из примера выше, то система уже будет думать, что у нас -26 акций, соответственно, она даст плечо на покупку этих 26 бумаг плюс 14 акций на собственные средства. Итого уже 40 акций.
С большим плечом дела пошли в гору, мой баланс на спекуляциях удалось увеличить до 6384$.
На скриншоте видно, как с помощью тех же манипуляций получилось увеличить плечо по Амазону почти до 200 000$. Таким образом оно уже стало более чем 1 : 30. Напомню, максимальное плечо у Тинькофф колеблется от 1 : 4 до 1 : 5.
Но вспоминаем, что ночью Тинькофф после пересчёта уберёт такое плечо и вполне вероятно, что на утро нас будет ждать маржин колл.
Маржин колл — такое состояние портфеля, при котором баланс становится меньше начальной маржи. При этом, если не пополнить счёт, брокер автоматически начинает продавать бумаги.
Что интересно: Тинькофф прислал маржинколл, хотя позиция прибыльная.
«Зачисляем» заёмные средства на брокерский счёт
Для того, чтобы заёмные средства зачислились на брокерский счёт, достаточно было самому вызвать маржин колл: очевидно, что никакой маржи не хватит, если, имея 6500$ купить бумаг на 300 000$.
При срабатывании такого маржин колла сразу после покупки, система начинает автоматически закрывать позиции. Но ведь до ночи система думает, что все «фейковые» заявки являются настоящими.
Поэтому, сделав -30 фейковых акций Амазона способом выше, я купил 40 акций на сумму более 120 000$. Сразу после покупки сработал маржин колл, и система моментально продала купленные 40 акций. Вместе с этим система сразу же отменила заявку на продажу 30 акций (помним, что до ночи система не знает, что заявка фейковая) и зачислила их мне на счёт. Вместе с 30 акциями на счёт зачислилось и 6 947 118₽ и стоимость ликвидного портфеля увеличилась до 7 337 776₽
АналитикаПортфельВывод средств
Таким образом, получилось увеличить депозит в 10 раз. Конечно, если вывести эту сумму, то на утро, когда отменятся все сделки, которые не были выведены на биржу, образуется отрицательный баланс на брокерском счёте. Однако, для злоумышленников это не было бы проблемой.
Все сделки, кроме «фейковых», были выведены на биржу, что подтверждается в брокерском отчёте.
Заключение
Таким образом, удалось столкнуться с необычной business logic уязвимостью, которая оказывает огромное влияние на брокера, а также показывает, насколько сегодня могут быть критичны недостатки в информационной безопасности.
Удобная система Тинькофф брокера с выводом средств с брокерского счёта в любое время суток показала, какой побочный эффект может быть достигнут.
