И Fairchild, и TI пытались основать производства в Японии ещё в начале 60-х, но наткнулись на жёсткое сопротивление MITI. В 1962 году MITI запретило Fairchild инвестировать в уже купленную в Японии фабрику, и неопытный Нойс попытался выйти на японский рынок через корпорацию NEC. В 1963 году руководство NEC, якобы действуя под давлением правительства Японии, добилось от Fairchild исключительно выгодных условий лицензирования, впоследствии закрывших Fairchild возможность самостоятельно торговать на японском рынке. Только после заключения сделки Нойс узнал, что президент NEC по совместительству председательствовал в комитете MITI, который блокировал сделки Fairchild. TI попыталась основать производство в Японии в 1963 году, уже имея отрицательный опыт переговоров с NEC и Sony. MITI в течение двух лет отказывалось дать определённый ответ на заявку TI (при этом вовсю воруя их микросхемы и выпуская у себя без лицензии), и в 1965 году США нанесли ответный удар, угрожая японцам эмбарго на ввоз электронной техники, нарушавшей патенты TI, и для начала забанив у себя на рынке Sony и Sharp.

Одна из статей Википедии по вроде как, узкой технической теме, которая читается как приключенческий рассказ:

https://ru.wikipedia.org/wiki/%D0%98%D0%B7%D0%BE%D0%B1%D1%80%D0%B5%D1%82%D0%B5%D0%BD%D0%B8%D0%B5_%D0%B8%D0%BD%D1%82%D0%B5%D0%B3%D1%80%D0%B0%D0%BB%D1%8C%D0%BD%D0%BE%D0%B9_%D1%81%D1%85%D0%B5%D0%BC%D1%8B

Хорошо идет вместе с (и взаимно-дополнено текстами): https://habr.com/ru/companies/onlinepatent/articles/723104/

На последней TeamleadConf один из докладчиков пожаловался на то, что на их микросервисное монорепо, все писанное на Go, перестало хватать разработчиков -- буквально вот не могут найти на рынке, конкуренция жёсткая даже между командами внутри (ха-ха, кто мог подумать? Вот бы кто-то об этом раньше написал!)

А я в связи с этим предлагаю вспомнить один пост из этого канала трехлетней давности, из которого становится ясно, почему делать микросервисы, но все писать на одном языке (а монорепо значит с вероятностью 99% и моноязык) это потенциальная глупость и ошибка 👇

Об микросервисы в который раз

Ну, хорошо, всем продали микросервисы: дескать, и устройство системы понятнее из-за них, и two pizza team вообще стандарт в Гугл ИТ, значит, и нам надо тоже. И код можно писать на самом подходящем языке: хочешь, пишешь на php, не хочешь, пишешь на nodejs, что очень удобно (особенно потом сопровождать комплекс, написанный на 10 языках). А еще можно переписать за две недели маленький микросервис, любой. Ну круто же, правда?! А еще архитектура очень отказоустойчивая, и если один сервис упал, то остальные выживут (на практике - не работает никогда). И самое главное - можно МАСШТАБИРОВАТЬ приложения! О том, что монолит тоже можно масштабировать, тем более сейчас, когда железо ничего не стоит, молчат.

Но это все selling points для недоверчивых технарей, а я расскажу, почему на самом деле бизнес выбирает микросервисы. Причин всего две:
1. Быстрая проверка гипотез, которые в 9 из 10 случаев проваливаются - да, продакт-менеджеры тоже не боги. В случае монолита вы стоите перед непростым выбором: или вкладываться по полной в эксперимент (дизайн, код, тесты), который, скорее всего, будет выброшен, или на коленке слепить то, что рискует выстрелить, и тогда с этим поделием придется жить вечно в монолите. Какой вариант хуже? Оба хуже. В случае с микросервисами эксперименты не сильно трогают ядро системы, которая кормит всю компанию и их семьи.
2. Найм. В ситуации, когда средней компании найти хорошего разработчика за праздник, в случае микросервисной архитектуры можно нанимать вообще любых программистов, которые подвернулись, а не те, которые подходят по стеку или согласны работать с легаси и т.п.

Эти две причины пересиливают все сложности, связанные с МСА. А сложностей немало, от оркестрации до смены парадигмы владения системами.

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

Об remoteproc

В комментариях к предыдущему посту (https://t.iss.one/architect_says/501) задают резонный вопрос: если Atmega не успевает даже вовремя выполнять деление, как вообще писать более-менее производительный код? Ну, как -- брать более мощный процессор. Правда, с этим начинаются нюансы.

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

Однако, ничего хорошего из этого не выйдет, есть принципиальные проблемы.

Во-первых, там установлен linux. Как заставить его забыть про 1 процессорное ядро, а на него повесить выделенную активность вне ОС -- это вопрос отдельного исследования. Да, есть Xenomai, есть китайский RROS, но всё равно это задача непростая.

Второе, и более сложное: несмотря высокую производительность ARM-ядра Cortex-Axx, оно менее детерминировано: тактовая частота в доменах плавает и троттлится, шиной доступа к периферии управляет арбитр, конвейер живет своей жизнью, как и механизм кэша, контроллер прерываний сам по себе сложнее, чем К580.
Между прочим, за одну микросекунду экран съезжает на 10 пикселей, мы себе не можем позволить дрожание (=неопределенность в обработке прерывания) даже в 500 нс.

Для решения такой ситуации ограниченными аппаратными средствами используется выделенное микроконтроллерное ядро, доступное как периферия и простое: никаких кэшей, никаких конвейеров, фиксированная частота, выделенный коммутатор шины: по сути, это микроконтроллер внутри процессора. Например, таким ядром оборудованы SoC Amlogic, TI или Allwinner. Иногда его могут назвать типа Power management core. Здорово, что в linux kernel начинают появляться зачатки подсистемы работы с ним: https://docs.kernel.org/staging/remoteproc.html

Работа с таким ядром темна и полна ужасов полна неожиданностей и "ОКР" (можно расшифровать как угодно). Слышал даже, что по этой причине некоторые поступающие к нам по параллельному импорту 😏 чипы остаются с отключенным ним, потому что на это просто нет документации, которую вендор передает за деньги и только особо избранным.

По многим китайским системам такая документация не только закрытая, но еще и есть исключительно на китайском.

..

СМОЖЕТ ЛИ НАШ ГЕРОЙ РЕШИТЬ ЭТУ ПРОБЛЕМУ? УЗНАЕМ В СЛЕДУЩИХ СЕРИЯХ

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

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

Причастных — с праздником

Об электропривод

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

Современные гаражные мастера поганых ИЗДЕЛИЙ в качестве него угорают по Ardupilot + PIХHAWK - связка проверенная, отлаженна. Почему он? Потому что имеет простой, деревянный код, ну и в целом адаптирована под самоуправление: например, есть планировщик миссий для автономного полёта. В полете оно напоминает надувной табурет, движется медленно, с грацией, однако задачу решает.

Тем не менее, в мире леталок своеобразным linux-ом остается ненавидимый мною бетафлайт, обладающий, как минимум, двумя родовыми травмами, препятствующими превращению в воздушное такси:
- Переполнение int32 счетчика времени после 2.7тыс секунд полета
- Аварийное отключение, встроенное в контур управления, в случае пропадания связи с пультом более чем на 500мс

Те, у кого было побольше времени (MILBETA), пошли простым путем и попробовали улучшить ситуацию, увеличив в 100 раз время самостоятельного полета, прежде чем автоматика отключит питание с винтов.

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

Для передачи команд автопилота на борт полетного контроллера можно воспользоваться тем же самым USB-портом полетника, через который Betaflight-configurator позволяет настроить параметры. Те, кто пользовался им, знают, что при подключении через этот порт, полетник переходит в режим принудительного disarm, во избежание нехороших последствий.

Фактически же оказалось, что disarm это всего лишь расширение протокола MSP, которое активирует конфигуратор, и эта опция не обязательная, то есть её можно обойти, так что ИЗДЕЛИЕ прекрасно летает и с подключенным кабелем, весело обмениваясь через него данными. Как передавать команды через этот порт, можно легко найти в интернете - адаптеры для MSP протокола есть для многих языках, в крайнем случае, можно распитонить питоновый yamspy. Контроллер штатно реализует канал управления поверх MSP.

Через этот адаптер ваши PID-регуляторы внешнего цикла из автопилота будут слать и получать пакеты - частота размыкания верхнего контура управления в 20-40 Гц вполне адекватна для рамы, нагруженной 3-7 кг ПИЦЦЫ.

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

Плюс этой схемы ещё и в том, что в случае же отказа автопилота ИЗДЕЛИЕ превращается просто в электронное копьё, которое держит по акселлерометру последний полученный курс, пока его полёт не окончится.

-

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

Об NLP

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

https://sysblok.ru/blog/gorkij-urok-abbyy-kak-lingvisty-proigrali-poslednjuju-bitvu-za-nlp/

Надумалось сыграть в Unreal Tournament, тот самый, из 1999 года. Оказалось, что D3D рендерер в Win11 работает отстойно, а софтверный рисует совсем не вдохновляюще, половина эффектов не видны.

Помогло решение, сделанное в свое время на века: эмулятор GLide->OpenGL в Win и движок 3dfx glide в самой игре. Всё летает, и картинка идеально соответствует той, что была тогда.

Умели, могли

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

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

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

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

Потом случился Agile

Крупная и неизбежная драма в ИТ, о которой никто не говорит – то, что работа не может быть местом интересных задач.

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

Или арендовать комплексную ИТ-инфраструктуру, если дома нет места для стоек.

Так что когда программиста завлекают "интересными задачами", это самое глупое, что можно сделать – всё интересное он уже сам попробовал, вы ему ничего не дадите.

Выгодное отличие ИТ от других мест работы – интересные задачи на фронтире технологий.

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

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

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

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

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

С этим вашим БЯМ ИИ возникают интересные вопросы, над которыми пока что не видно, чтобы задумывались.

Например, если раньше нарисовать "в чём-то стиле" не значило стиль украсть (что такое стиль? как его "извлечь"?), то теперь можно продемонстрировать – стиль это отчуждаемая сущность.

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

Знание может стать 100% эмпирическим

Спустя примерно 20 лет аналитики заметили предметно-ориентроанное проектирование (DDD в трендах!), но перевести на русский правильно все ж таки не смогли:

https://trends.rbc.ru/trends/innovation/cmrm/6763ff619a7947ef288bdce4