В программировании микроконтроллеров часто возникает задача найти угол между векторами.

Это всяческие встраиваемые системы, где есть подвижные, вращающиеся детали: PTZ камеры, поворотные платформы для радаров, турели, ветрогенераторы, солнечные панели, SDR обработка и прочее.

В данном тексте я приведу простое и понятное решение задачи вычисления угла между векторами на языке программирования Си.

• засилье KPI с последующей деградацией продукта, которое по менеджерской логике должно увеличивать DAU;
  
• деградация корпоративной культуры из-за офисных интриг и карьеризма;
  
• снижение продуктивности разработчиков из-за бесконечных совещаний, созвонов, отчётности и использования ПО для «повышения эффективности» (таск-трекеры, тайм-трекеры, календари и проч.);
  
• цифровое истощение и выгорание сотрудников.

Сложно представить, что 70–150 лет назад приходилось прокладывать маршруты, вести бухгалтерию, производить сложные вычисления (а каких-то 60 лет назад уже и запускать в космос людей), без использования компьютеров. Так как же решались задачи, выполнение которых сегодня невозможно представить без использования современных технологий?

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

На иллюстрации: компьютер XV века по версии Midjourney.

Да вымереть не могут.

Откуда это всё пошло? Чем так условные «программисты» не угодили? И почему именно программисты?

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

О том, как их развить, рассказываем под катом.

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

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

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

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

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

Привет, Хабр! Меня зовут Ирина Ремизова, я куратор департамента системного анализа Sportmaster Lab, где, собственно, и курирую системных аналитиков, развивая их и рассказывая про инструменты принятия решений.

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

Начнём мы с ББМ. Это аббревиатура из трех слов, которая представляет собой три реакции человека при принятии решения. Боль (приобретение или потеря), боязнь сделать неправильное решение (верно или неверно) и муки (а что было бы, если…).

Почему бывает так трудно? 

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

Ещё есть межличностные проблемы. Вы приняли какое-то решение, которое повлияло на кого-то другого. Реакция этого человека тоже влияет на вас, поэтому при принятии решения можно сохранить отношения (или потерять их). 

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

Сегодня в методах разработки ПО исключения не подтверждают, а скорее заменяют правила. Чистокровный Аgile днем с огнем не сыщешь ни в одной компании. Зато плодятся разные гибридные методологии. Некоторые проджекты задаются совсем уж крамольным вопросом: зачем нужны эталонные системы, если на практике все работают по-разному?

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

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

Часто приходится слышать: наука вне политики, наука вне идеологии, потому наука никак с моралью не связана, и рассматривать вопросы морали или политики в науке – это попросту глупо. Действительно, на первый взгляд, так и есть. Если, к примеру, я – клеточный биолог, то какая связь между тем, за кого я голосую на выборах, и тем, что я исследую в микроскоп? Разве может быть хоть какая-то связь? Любому же понятно, что нет….

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

Я хотел бы рассмотреть один красочный пример из истории 80-летней давности. Он касается гиков того времени, «красноглазиков» 30-40-х годов 20-го века, – квантовых физиков. Они во многом, как и мы, современные программисты-исследователи из мира IT, не сильно заботились вопросами того, какие последствия принесут их исследования и наработки: положительные или отрицательные, а если отрицательные, то насколько.

Между ними тогдашними и нами сегодняшними очень много общего: и в психологии, и в месте в обществе, и в отношении к исследованиям, и даже в такой, казалось бы, мелочи, как пренебрежение изучением общественных дисциплин. Смотря на 80 лет назад, в них я вижу себя и людей, которые меня окружают в программистском и исследовательском сообществе здесь и сейчас. Они создали атомную бомбу – совершенное и смертоноснейшее оружие. Причем практически не задумываясь о последствиях. А что создаем прямо сейчас мы?

Отбросьте невозможное — и то, что останется, каким бы невероятным оно ни казалось, должно быть истиной
"Знак четырех", Артур Конан Дойл

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

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

«Мужики! Я вам запрещаю выпускать меньше 200 тонн хлеба в сутки», — примерно это 92 года назад заявил Георгий Марсаков, и перевернул игру, создав инженерное чудо. Что же такого он придумал?

Давайте разбираться.

От переводчиков. Хотя Эдсгер Дейкстра — одна из главных личностей в истории IT, эта его коротенькая публикация ранее не попадала на Хабр, да и сами мы узнали о ней лишь благодаря докладу на нашей конференции. Но при этом она выглядит очень любопытным документом эпохи, показывая, что ещё несколько десятилетий назад люди думали о перспективе писать программы на «обычном языке». Поэтому мы решили восполнить пробел и перевести.

С первых же дней появления автоматических вычислительных машин были люди, которые считали недостатком тот факт, что программирование требует внимательности и точности, свойственных любому формального символизму. Они критиковали механического слугу за то неукоснительное выполнение данных ему инструкций, когда достаточно было бы поразмышлять мгновение, чтобы заметить, что в этих инструкциях есть очевидная ошибка. «Но мгновение — это долго, а размышлять — болезненный процесс». (А. Э. Хаусман). Они страстно надеялись и ждали появления более разумных машин, которые отказались бы приступать к таким бессмысленным действиям, какие в то время вызывались банальной опечаткой.

• Мы поняли, что ML в 50% задач не нужны. Нужна, например, камера, которая по цвету определяет, где есть железка, и смотрит её геометрию в реальности. Всё. Или другая камера, которая следит, чтобы в нужной зоне ничего не шевелилось.
• Всё это прекрасно до первого солнечного зайчика. ML отлично показывают себя там, где вам лень строить крышу или ставить прожектор над конвейером.
• У нас была идея, что мы можем сами в нейросети. Чуть не написали свой сервис для распознавания номеров вагонов. Казалось, делов-то на 20 минут, а у подрядчика это стоит 25 копеек за фото. Сделали свой, сферические вагоны в вакууме он определял хорошо. Потом приехало вот это:

Привет, Хабр! Я Ульяна, старший аналитик в направлении продуктового и системного анализа в отделе Tinkoff Mobile Core. Наш отдел разрабатывает общие технические решения — библиотеки, которые используются в мобильных приложениях экосистемы Тинькофф.

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

Документацию мы ведем в Confluence — и обычно, когда я рассказываю про Confluence, у многих он вызывает, мягко говоря, неприятные ассоциации. Миллион разделов, неудобная навигация, портянки бесконечного текста и многое другое, что отбивает желание даже открывать любую wiki. Но я спешу вас обрадовать — все может быть совсем иначе!

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

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

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

Что такое отказоустойчивость и стабильность?

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

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

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