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

Занимаясь БПЛА с 2016 года, я решил разобраться в устройстве полетных контроллеров максимально глубоко и создать квадрокоптер с нуля, не используя готовый полетный контроллер и готовый софт. Спустя долгое время разработки мне удалось это сделать. Я написал прошивку с максимально простым исходным кодом и выложил ее на GitHub. В этой статье я расскажу о теории и практике разработки полетного софта для квадрокоптера и проиллюстрирую это на примере своего дрона на базе микроконтроллера ESP32, который можно увидеть на картинке выше.

В какой-то определенный момент после старта нового проекта, когда «временный» MVP почти готов, весь интересный код уже написан, пакеты еще свежие и обновляются, команды начинают замедляться в Time to Market.

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

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

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

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

Стартапы в последние пару лет, мягко говоря, оказались между Сциллой и Харибдой. Многие бизнесы начали сжиматься (а ЦБ стран жестить), а венчурные фонды внезапно стали очень бережливыми. Как поступают стартапы в США в эпоху неопределенности? Правильно, сразу сокращают персонал и закрываются. Сегодня все уже забыли оптимизм постковидного 2021 года. 

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

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

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

Различные методы эволюции ключей (терминология не устоялась, предпочитаю использовать такой перевод словосочетания «key-evolving techniques») асимметричных криптоалгоритмов позволяют защититься от компрометации секретных ключей путем периодической модификации ключевых пар. Подобная защита направлена не на предотвращение компрометации секретного ключа, а на минимизацию последствий такой компрометации: поскольку ключи периодически модифицируются, эволюционируют, данные методы позволяют ограничиться отрицательным воздействием компрометации ключа на свойство целостности или конфиденциальности сообщений, зашифрованных или подписанных только в течение определенного, относительно короткого периода, оставляя защиту сообщений других периодов ненарушенной. Большинство протоколов с эволюцией ключей подразумевает достаточно активный обмен сообщениями между сторонами защищенного обмена данными. При этом бывают сценарии, когда возможности для интерактивного взаимодействия у сторон отсутствуют.

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

Уважаемые читатели, эта статья будет для вас полезна, если:

• Вы являетесь действующим архитектором ИТ и вам необходима дискуссия с коллегами о роли архитектора;

• Вы хотите стать архитектором, но еще не осознали, кто это;

• С вами рядом работает архитектор, и вы не понимаете, чем он занимается;

• Вы не владеете английским, но давно хотели прочитать книгу западного автора по архитектуре;

• И в целом если вы интересующийся современными веяниями ИТ, а именно архитектура является популярным запросом от работодателей в виду растущих масштабов автоматизации.

Если вы когда-нибудь слышали фразу "дьявол в деталях", вы понимаете, что условная Лада Гранта от условного Мерседеса отличается не более, чем на несколько процентов. Фактически обе машины ездят и возят своих пассажиров - это и есть главная их функция. Но внимание к мелочам и продуманный пользовательский опыт (UX) это и есть те самые несколько процентов, которые так разительно влияют на наше восприятие продукта.

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

Всем привет! Я достаточно давно в разработке и мне приходилось видеть разные вариации гибких методологий управления проектами. Чаще всего я встречал такую картину: вроде есть спринты, дейли, иногда даже демо, отчеты, но все равно, получив набор фичей от бизнеса, команда не могла сказать достаточно быстро (где-то в течение недели), сколько времени ей потребуется на реализацию. Со временем я пришел к своей спринтовой модели, которая позволяет моей команде довольно точно и быстро давать оценку трудозатрат, что в итоге приводит к успешному попаданию в дату релиза.

Здравствуйте друзья, я хочу поделиться с вами своим опытом в отладке ESP32 с помощью отладчиков, реализующих интерфейс JTAG. Данная задача кажется тривиальной (она такая и есть), при мысли об программировании микроконтроллеров. Но при старте работы с микроконтроллерами ESP32 я столкнулся с рядом проблем, о которых я хочу рассказать и от которых хочу уберечь вас.

Почему, зачем, для кого написана эта статья?

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

Распространение вирусного софта в сети с каждым годом становится все изощреннее и изощреннее, чего только злоумышленники не придумают, чтобы «заразить» ваше устройство: используют уязвимости, фишинг, USB‑jacking. Во всем этом динамичном развитии методологии заражений прослеживается одна лазейка, которая возникла с первыми программами, требующими покупку лицензии. Ведь появились сайты с «крякнутым» ПО, в 90% которых содержится какой‑никакой зловред. Произведем анализ последних нашумевших вирусов, которые распространялись через такие веб‑порталы и проведем небольшое исследование, в котором определим реальную вероятность заражения, устанавливая разнообразные «кряки» на своё устройство.

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

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

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

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

Всем привет!

Меня зовут Коля, и я периодически собеседую кандидатов на позицию системного аналитика. За последние два месяца провёл порядка 20 десятков собеседований. В основном были кандидаты с опытом 1.5-3 года, на пути к уровню Middle и с зарплатными ожиданиями 150-200 тысяч рублей в месяц.

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

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

До последнего времени у отдела менеджеров не было такой системы и это вызывало непредсказуемые решения в управлении кадрами и распределении проектов.

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

Мой мадригал тем инструментам разработки, которые изменили мою жизнь

Программирование стало гораздо более многогранным ремеслом с тех пор, как в середине 1990-х я впервые попробовал AmigaBASIC. В те времена еще можно было купить один большой том о компьютере, на котором вы программируете – и там бы нашлось 99% всей нужной информации. Эта книга, где на множестве страниц уголки загнуты в качестве закладок, обклеенная стикерами, лежала бы у вас под рукой, пока вы вбивали бы команды в монохромный текстовый редактор.

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

Сегодня никто бы больше и не подумал покупать документацию по разработке – и Microsoft, и Apple свободно выкладывают свою документацию в Интернете для всех желающих. А что говорить о проектах с открытым исходным кодом!

Во времена npm, PyPI и GitHub сложно объяснить, насколько неоднозначным решением (которое требовалось всесторонне обдумывать) раньше считалось потребовать хоть какие-нибудь возможности, которые выходили бы за рамки функционала операционной системы. Часто вместе с продуктом приходилось сдавать и все его зависимости.

1. Уговаривать стратега на любую зарубежную юрисдикцию (а для них бы это был первый опыт инвестиций в зарубежный проект);
2. Как только они дадут добро, за недельку зарегистрироваться, например в Делавере, и принять деньги.