Нет - потому что я вижу и замечаю тенденцию последних лет этак пяти-семи - снижение планки требований к архитектору и вульгаризацию его работы. Уже мы перестали требовать от архитектора опыта работы вообще и в предметной области в частности. Уже мы сводим работу архитектора к правильной записи таблицы NFR/QA и подбору по другой таблице тактик и компонентов. И я никак не могу понять - откуда это, блин, идет! Понятно что в ИТ всё девальвируется, но не до такой же степени! Завтра у нас LLM архитектором станет такими темпами!
Еще раз повторюсь - записывать таблички QA/NFR - большого ума не надо. Говорить что система определяется требованиями клиента - тоже большого ума не надо. Только не надо называться архитекторами тогда наверное. Потому что в реальной жизни - клиенты понятия не имеют что им на самом деле надо (хорошо если могут внятно рассказать что у них болит). Клиент который честно в этом признается - на вес золота. Остальные еще и врут как сивые мерины по разным причинам (от желания показаться умнее до искренних заблуждений по поводу себя, рынка и своего места на нем).
А задача архитектора - в условиях когда никто толком ничего не знает, так разбить систему на составные части, и так их между собой связать - чтобы когда туман начнет рассеиваться, и появятся требования которые никто в глаза не видел и до того о них не знал - то за разумные время и деньги можно было бы под эти требования подстроиться. И обеспечить тем самым срок функционирования системы хотя бы лет 10-15 (прежде чем станет "проще снести и заново построить, чем модернизировать").
И я настаиваю, что именно учет незаявленных, неосознанных, и несуществующих в моменте требований - это и есть то, для чего привлекается архитектор. Заказчик имеет право НЕ привлекать его к работе, и по-честному - не в каждом проекте архитектор нужен. Просто в последнее время модно везде его пихать и делать вид что без архитекта программисты не знают как код писать с учетом не только FR, но и NFR. Но это - следствие девальвации инженерной профессии в разработке ПО. Раньше - умели!
Логика в программе обучения - это прекрасно. Однако здравый смысл никто вам не отменит, ибо всякая достаточно сложная система либо неполна, либо противоречива. :-) Живите с этим. На всякий случай объясню еще раз. Человека никто не проектировал (если только вы не сторонник креационистской теории - но это уже к теологам, а не ко мне). Однако, практика показала что результат получился исключительно удачным. И мы можем указать на решения, которые делают его таковым.
Когда мы говорим о программных (и шире - о технических) системах - то их создание предполагается как осмысленный процесс, а не как случайные мутации, скрещивание, и миллионы лет отбора. Соответственно, вам придется применять мозг и имплементировать решения которые позволят получить такой же результат как у матери-природы за миллионы лет, только в миллион раз быстрее. Вот это и есть архитектура...
Вот архитектор вам на то и архитектор, чтобы объяснить ПОЧЕМУ вы должны некоторый ресурс потратить сейчас даже если не видите в этом необходимости. Потому что если этого не делать - тогда это просто инженерия: вот требования, вот нормы, бах-трах, подписывай акт хозяин - мы все сделали. Надо оно вам, не надо оно вам - это не инженера проблема, а заказчика.
У архитектора - задача сложнее. Он должен понять чем заказчик живет и что у него болит. И да, предложить решение в рамках существующих ресурсных ограничений. Например, в СССР архитекторы с учетом ограничений предложили массовое панельное домостроение. А в США - suburbs с деревянными каркасниками. А если все совсем плохо - архитектор может вам вообще сказать что с такими ресурсами ничего строить не получится...
И да, в ситуации когда о будущем мы не думаем (у кого-то правительство долбанутое: то войну затеет, то бизнес отберет; у кого-то климат меняется и сгорает все периодически, и т.д.) - то архитектура не нужна. Нужно отмыть деньги сейчас, что-то построить лишь бы не упекли в казенный дом за хищения, а завтра уже ни заказчика нет, ни строителя, ни строения... Если вы это считаете за норму - я вам сочувствую...
Я сказал "хорошей архитектуры", а не "идеальной". Оно выжило при нескольких глобальных похолоданиях, заселило все континенты кроме Антарктиды, живет во всех климатических поясах от Сахары до Чукотки. Понятно, что человека никто не проектировал - я это привожу как пример "случайно удачной" архитектуры которая прошла эволюционный отбор и оказалась достаточно хороша для широкого круга применений. А другие - более специализированные виды - нет... Вопрос об идеальной архитектуре я бы оставил открытой, ибо в какой-то момент вы упретесь в Парето-оптимальность и сможете только менять одни недостатки на другие...
Нет, нет, и еще раз нет! Архитектура - это искусство выстраивания системы сейчас под требования, которые в моменте не предъявляются, не осознаются, и возможно даже не существуют. Проектирование системы под известные требования - это инженерия.
Еще раз повторяю пример, который я привожу разработчикам. К вам приходит молодой человек увлекающийся конным спортом с требованием спроектировать загородный домик с конюшней как можно ближе, чтобы утром выезжать в поле на коне. Инженер вполне может под эти требования сделать конюшню на первом этаже, а жилые помещения на втором, при условии что толщина стен рассчитана на непромерзание зимой, а стропила - на ветровую и снеговую нагрузку. Архитектор же из своего опыта и общей эрудиции - понимает что одинокий молодой человек не всегда будет одиноким и молодым. И поэтому сразу ("вотпрямщас") закладывает в конструкцию избыточность, определяя конюшню отдельным строением, и прокладывая к ней удобную дорожку.
Пример плохой архитектуры - это трущобы какого-нибудь мумбая или сан-паоло. При любом изменении обстановки - они подлежат сносу (если не рухнут сами или сильный дождь не смоет). В противовес этому, примеры хорошей архитектуры - например, дворцовые комплексы, продолжают использоваться даже сейчас (хотя функцию "родового гнезда" или "цитадели знати" уже давно не выполняют).
Другой пример хорошей архитектуры - это человек. У вас достаточно точек гибкости в скелете, чтобы вы могли достать рукой до любого места тела (хотя и с разной степенью удобства). Если бы это было не так - можно было умереть загнав себе небольшую занозу и не имея возможности ее вытащить, и далее сепсис и проч... С другой стороны - в отличие от бесконечно гибкого осьминога - вы достаточно жестки чтобы жить на суше, переносить достаточно тяжелые предметы, манипулировать инструментами. Хотя при рождении, когда задачей является спать и есть мамкину грудь - важность этого функционала совершенно не очевидна.
Сухой итог - архитектура это действительно компромисс. Компромисс между сложностью системы и ее возможностью адаптироваться к неизвестному будущему. Работа архитектора - не сводится к подбору компонентов под требования (хотя и это тоже надо делать). Настоящая работа архитектора (его насмотренность, опыт в отрасли и т.д.) - это сказать вам СЕЙЧАС как надо сделать, чтобы ПОТОМ каждый раз оказывалось: "...могла ли природа предполагать что нам понадобятся очки? А как удачно расположены наши уши!...". То есть, внешний мир изменяясь предъявляет новые требования к вашей системе - и внезапно оказывается что относительно небольшой кровью она может к ним адаптироваться. А у конкурента, который строил как лачуги в мумбае - нет!...
Вы всегда можете увеличить размерность пространства - и там задать какую хотите метрику чтобы что угодно оказалось рядом, или наоборот далеко. Я нахожу в этой работе известные пересечения с классической теорией Вапника-Червоненкиса. В пространстве достаточной размерности, по нескольким примерам вы (статистически) всегда можете провести гиперплоскость которая "достаточно хорошо" разделит примеры на два класса. Свойство выпуклости может оказаться интересным дополнением, потому что В&Ч дают скорее верхнюю границу для количества примеров. Реальные сетки успешно учатся на много меньшем (порядки) размере данных. Выпуклость хорошо объясняет - почему...
Соглашусь. Это два разных инженерных решения. Но я не знаю, какое из них проще в реализации. Камера высокого разрешения позволяет легко находить цели, но чтобы прицелиться - вам нужна точная механика (я не уверен что простые авиамодельные сервы, например, подойдут). Скорее всего, придется городить обратную связь по положению - или с камеры по положению пятна, или с зеркал.
Решение с вращающимися зеркалами крайне простое механически (обороты относительно невелики - сотни оборотов в минуту). Подшипники при такой нагрузке могут работать десятки тысяч часов - доказано компьютерными вентиляторами. Нет необходимости в обратной связи по положению - зондирующий луч гарантированно идет по той же траектории что и боевой: если вы стреляете с одинаковой задержкой (T1, T2) - то в каждом цикле попадаете в одно и то же место. Но придется повозиться с детекцией комара в модулированном отраженном сигнале.
Дальше, наверное, только решение конструктора - с чем он предпочитает бороться. Я, например, больше боюсь безлюфтовой механики и точных приводов с обратной связью...
А кто говорит что лазер должен работать на 100% мощности постоянно ? Ток же можно регулировать через голову... Работает голова на 5 или 10 процентах мощности в зондирующем режиме. При обнаружении комара, он берется на сопровождение на проходе и вычисляется момент выдачи импульса на поражение на следующем проходе. А зеркала вращаются с постоянной скоростью и непрерывно - самый лучший режим для механики, никаких переменных нагрузок...
Если мы разворачиваем луч вращающимися зеркалами - то при постоянной скорости вращения нам надо только датчик который постоянно и предсказуемо дает один импульс на оборот на каждом зеркале. Запустив таймер в микроконтроллере по фронту этого импульса - мы в каждый момент времени будем знать углы поворота зеркал относительно реперной точки. Таким образом, координата комара будет задана двумя временами (T1, T2). И нам, в целом, даже не очень интересно переводить это через скорости вращения зеркал в более привычные углы сферической системы. Можно так и рассчитывать в системе (T1, T2) - потому что на следующем сканировании мы будем по комару производить боевую работу в момент (T1+t1, T2+t2), где (t1, t2) вычисленный вектор (в тех же координатах) видимого углового перемещения комара из предыдущих наблюдений. А фотодиод скорее всего смотрит в те же самые линзы (и тогда он гарантированно смотрит по тем же координатам), либо вообще с широким углом зрения (нам важно поймать модуляцию лазерного луча - длина волны известна - комариными крыльями на частоте 200-600 гц). Если поймали модулированный сигнал - значит лазер прямо сейчас светит на комара.
Камера высокого разрешения не нужна. Комар детектируется по модуляции отраженного излучения взмахами крыльев - достаточно фотодиода и полосового фильтра (аналогового, цифрового - уже неважно). Вы стреляете по любой цели которая а) модулирует отраженный свет в диапазоне 200-600 Гц и б) Попадает в разрешенный диапазон угловых скоростей (чтобы не лупить почем зря по какой-нибудь волосинке которую треплет сквозняк из окна). Разумеется, при этом исключается атака стационарных комаров - но вроде не должно быть проблемой...
Кстати да - классическая задача радиолокации "сопровождение на проходе". Даже несколько проще, потому что с одним излучателем нас не интересует в разумных пределах расстояние до цели - задача двумерная в сферичеких координатах. Каждый проход вычисляются корреляции отметок с нескольких предыдущих, определяется вектор движения цели, и на следующем проходе включается (с гораздо меньшими допусками!) боевой режим.
А кто мешает поставить один главный блок и два-три вспомогательных по углам комнаты ? Тогда мощность единичного излучателя упадет в те же два-три раза. Основной блок выполняет сканирование объема лазером на низкой мощности и ловит модуляцию отраженного излучения в частотном диапазоне взмахов крыльев насекомого характерного размера. Выбрав цель, базовый модуль берет ее на сопровождение в непрерывном режиме, и сообщает об этом вспомогательным модулям. Те просто наводятся на самое яркое пятно в заданном секторе и сопровождают его. Когда все три устройства вышли на режим сопровождения, дается импульс. При этом на цели импульсы складываются (и это единственное место в пространстве где они сложившись - опасны).
Кроме того, требование "перемещение не быстрее 1 м/c" намекает что уничтожение комара будет происходить не миллисекундными импульсами, а скорее всего на относительно низкой мощности и долго. И я бы не стал жечь крылья. Вполне достаточно нанести существенные повреждения ногам/хоботку/телу (а они прекрасно поглощают излучение, и в силу геометрии не смогут сбросить энергию в массивную тушку) - так что у комара возникнет масса других неотложных дел, чтобы он прекратил приставать к людям...
Дурацкая еще идея (но это надо считать) - вообще делать устройство без следящей системы. Просто вращающиеся зеркала и механическая развертка в двух плоскостях. Лазер в дежурном режиме работает на малой мощности и запоминает участки на которых возвратное излучение модулировалось крыльями насекомых. На следующем сканировании - в этих участках (+-допуск по обеим координатам) дается боевой импульс. Если повезло - накрыли. Не повезло - значит не повезло: у нас нет задачи снять комара с воздуха первым же выстрелом. Пусть летает по комнате дальше - поймаем его на следующем цикле сканирования, или через один. Более того, нам не надо даже взрывать его изнутри одним импульсом - достаточно просто наносить какие-то повреждения при попадании. Если мы обеспечиваем сканирование хотя бы с частотой 10-15 герц по объему - через 5-10 секунд комар забудет что он сюда прилетел кушать (или ему будет нечем...).
Да, но у компьютера нет рук, и он сам никогда не играл... Но посмотрим - может быть действительно если обучить его на многих партиях и многих исполнениях, он сможет чисто на выявленных закономерностях "сделать похоже"...
Фортепиано - чуть ли не единственный музыкальный инструмент игра на котором гарантированно не требует каких-либо особых навыков или таланта. Нажми на кнопку - получишь результат. Понятно дело, что виртуозно играть на фортепиано дано немногим. Но опыт имущих классов российской (и не только) империи доказывает - любой аристократ (т.е. даже мозги в голове не гарантируются) при правильной дрессировке преподавателем и родителями может средне-паршиво играть на фортепиано. Там это было совершенно массово, и в обязательном порядке...
Ну, во-первых фактура для диктанта выбирается такая, чтобы средний ученик музшколы ее смог записать. :-) Во-вторых, мне все-таки кажется что учащийся муз.школы дошедший до этого момента - уже имеет достаточную практику игры на инструменте, и пишет не "что слышу, то пишу", а прикидывает как бы он это сыграл - и на этой основе "как бы я это записал чтобы потом сыграть". Если же диктант проводится на тему "Савка и Гришка сделали дуду..." - то это понятно любой кого жизнь приложила об музыкальную школу запишет хоть на слух, хоть по памяти, хоть вверх ногами, хоть задом наперед...
Вот вы убейте меня - но я не верю в то, что можно из звукового файла вернуть обратно нотную запись (если это не чижик-пыжик одной рукой, и мы не читерим распознавая произведение и потом вытаскивая из запазухи честно спиратченые ноты...). Ноты это же не просто информация о том, в какой момент какую клавишу нажали! Это же еще и момент когда ее отпустили (а это пересекается с педалью!). Информацию о многих голосах в одной руке (которая в оригинале передавалась лигами) из звука не восстановить - там вообще неизвестно каким пальцем какой руки ноту брали. Изменения ритма в одном такте (см Таривердиева, например) - откуда оно поймет ?! Плюс живой музыкант не играет как метроном или музыкальная табакерка - на записанные инструкции композитора накладывается личная интерпретация. Как они собираются осеивать одно от другого ? А выделить атаки нот - тут ИИ не надо. Товарищ Фурье давно всем объяснил как выделять спектры...
Мне кажется что китайцы или не хотят производить полностью готовые изделия, или не умеют, или просто прикалываются. И это не зависит от цены. Я на примере 3д-принтеров видел: отличный аппарат, хороший корпус, линейные рейльсы (причем, приличного качества), собрано без перекосов, все катается, и... дребезжащий endswitch который не дает ему нормально печатать (исправление стоит ~$2 - меняем на оптический). Или сделать один из проводов до головы на 8см короче остальных чтобы голова не доставала до дальнего угла... Или экструдер который не позволяет разгоняться хорошей кинематике CoreXY. Или кривой софт, который борется с резонансами не на тех частотах где они есть. Парадокс в том, что исправление стоит копейки (а в условиях завода вообще ничего не стоит - пользователь не заметит изменение цены на копейку)...
При этом, то что реально стоит денег (и невозможно сделать на коленке или даже в мастерской) - сделано нормально, вопросов нет. Но положить какашечку на тортик вместо вишенки - как здрасьте... Ментальность один в один с советским велосипедным заводом: и металл годный, и подшипники ГПЗ положили, и седушку кожаную на пружинах сделали - такая красота, что аж глаза режет! Ну давайте хотя бы болты крепления багажника молотком криво забьем.. :-)
Покупать на алике можно и нужно! Просто не надо ждать что вы покупаете готовое изделие... Как в старые добрые советские времена - вы покупаете набор для творчества! В этом наборе вы найдете кучу добротных компонентов, из которых сможете с небольшими услиями собрать именно то, что вам нужно. Ну а то что не с той стороны отверстия насверлили - это не беда. Когда мне, пацану, купили первый взрослый велосипед - первое что мы сделали с отцом - это его полностью разобрали, вымыли песок из подшипников, прошли метчиком резьбы куда винты забивали молотком, выпрямили держатели крыльев - и он был огонь-машина! А если вы хотите просто отдать денег, включить и поехать, то это всякие буржуйские боши-сименсы. Эти, дай им волю, и еду за вас есть будут...
А почему вы считаете, что чтение и разбор кода после LLM займут сильно меньше времени, чем просто его реализация ? В современных фреймворках "тупая" часть тестирования (моки, ассерты) уже реализована: знай себе инициализируй объекты да проверяй результат... Еще раз - я не против ИИ помогающего писать тесты. Я против ИИ, которому ставят KPI по покрытию (и отбирают тесты целенаправленно на увеличение покрытия). Я (возможно с развитием ИИ это изменится) стою на том, что happy-path тесты должен писать разработчик (потому что ИИ понятия не имеет о бизнес-контексте). А вот анализ покрытия и идентификацию бизнес-кейсов которые не покрыты текущими тестами - вполне можно доверить ИИ. Но эти кейсы должен глазами посмотреть разработчик (т.е. они должны быть сгенерированы в человеко-читаемом виде!), возможно их отредактировать - и потом уже пусть ИИ их реализует (если может). А когда мы показываем человеку PR в котором уже сгенерирован десяток тестов - то или теперь ему придется восстанавливать по коду - какие бизнес-кейсы имелись в виду (и почему), или человек просто перекрестится и нажмет 'Approve' не вдаваясь в подробности...
На самом деле, есть два существенно разных сценария. Вариант 1: перед нами некое легаси, которое надо перетащить на новую версию фреймворка, или запихнуть в облако, или что-то там еще. Мы знаем что оно сейчас работает - это подтверждается практикой. Однако, как во всяком легаси - часть тестов сломана, часть закомментирована, и уже никто не знает почему. Если мы хотим прибить к столу текущий функционал и убедиться что мы его не сломаем в процессе миграции - наверное робот - лучший вариант. Приколотит так что потом зубами не оторвешь. :-)
Если же у нас Вариант 2: идет итерация разработки - то я с вами согласен: инструктировать LLM написать тест который "builds and passes" на непроверенный код - это только создавать себе иллюзию тестирования. Я так в одном проекте видел сервис с зелеными тестами, который в принципе не запускался (функции взаимодействия с БД дописать забыли - но с моками-то все было в порядке!)...
Нет - потому что я вижу и замечаю тенденцию последних лет этак пяти-семи - снижение планки требований к архитектору и вульгаризацию его работы. Уже мы перестали требовать от архитектора опыта работы вообще и в предметной области в частности. Уже мы сводим работу архитектора к правильной записи таблицы NFR/QA и подбору по другой таблице тактик и компонентов. И я никак не могу понять - откуда это, блин, идет! Понятно что в ИТ всё девальвируется, но не до такой же степени! Завтра у нас LLM архитектором станет такими темпами!
Еще раз повторюсь - записывать таблички QA/NFR - большого ума не надо. Говорить что система определяется требованиями клиента - тоже большого ума не надо. Только не надо называться архитекторами тогда наверное. Потому что в реальной жизни - клиенты понятия не имеют что им на самом деле надо (хорошо если могут внятно рассказать что у них болит). Клиент который честно в этом признается - на вес золота. Остальные еще и врут как сивые мерины по разным причинам (от желания показаться умнее до искренних заблуждений по поводу себя, рынка и своего места на нем).
А задача архитектора - в условиях когда никто толком ничего не знает, так разбить систему на составные части, и так их между собой связать - чтобы когда туман начнет рассеиваться, и появятся требования которые никто в глаза не видел и до того о них не знал - то за разумные время и деньги можно было бы под эти требования подстроиться. И обеспечить тем самым срок функционирования системы хотя бы лет 10-15 (прежде чем станет "проще снести и заново построить, чем модернизировать").
И я настаиваю, что именно учет незаявленных, неосознанных, и несуществующих в моменте требований - это и есть то, для чего привлекается архитектор. Заказчик имеет право НЕ привлекать его к работе, и по-честному - не в каждом проекте архитектор нужен. Просто в последнее время модно везде его пихать и делать вид что без архитекта программисты не знают как код писать с учетом не только FR, но и NFR. Но это - следствие девальвации инженерной профессии в разработке ПО. Раньше - умели!
Логика в программе обучения - это прекрасно. Однако здравый смысл никто вам не отменит, ибо всякая достаточно сложная система либо неполна, либо противоречива. :-) Живите с этим. На всякий случай объясню еще раз. Человека никто не проектировал (если только вы не сторонник креационистской теории - но это уже к теологам, а не ко мне). Однако, практика показала что результат получился исключительно удачным. И мы можем указать на решения, которые делают его таковым.
Когда мы говорим о программных (и шире - о технических) системах - то их создание предполагается как осмысленный процесс, а не как случайные мутации, скрещивание, и миллионы лет отбора. Соответственно, вам придется применять мозг и имплементировать решения которые позволят получить такой же результат как у матери-природы за миллионы лет, только в миллион раз быстрее. Вот это и есть архитектура...
Вот архитектор вам на то и архитектор, чтобы объяснить ПОЧЕМУ вы должны некоторый ресурс потратить сейчас даже если не видите в этом необходимости. Потому что если этого не делать - тогда это просто инженерия: вот требования, вот нормы, бах-трах, подписывай акт хозяин - мы все сделали. Надо оно вам, не надо оно вам - это не инженера проблема, а заказчика.
У архитектора - задача сложнее. Он должен понять чем заказчик живет и что у него болит. И да, предложить решение в рамках существующих ресурсных ограничений. Например, в СССР архитекторы с учетом ограничений предложили массовое панельное домостроение. А в США - suburbs с деревянными каркасниками. А если все совсем плохо - архитектор может вам вообще сказать что с такими ресурсами ничего строить не получится...
И да, в ситуации когда о будущем мы не думаем (у кого-то правительство долбанутое: то войну затеет, то бизнес отберет; у кого-то климат меняется и сгорает все периодически, и т.д.) - то архитектура не нужна. Нужно отмыть деньги сейчас, что-то построить лишь бы не упекли в казенный дом за хищения, а завтра уже ни заказчика нет, ни строителя, ни строения... Если вы это считаете за норму - я вам сочувствую...
Я сказал "хорошей архитектуры", а не "идеальной". Оно выжило при нескольких глобальных похолоданиях, заселило все континенты кроме Антарктиды, живет во всех климатических поясах от Сахары до Чукотки. Понятно, что человека никто не проектировал - я это привожу как пример "случайно удачной" архитектуры которая прошла эволюционный отбор и оказалась достаточно хороша для широкого круга применений. А другие - более специализированные виды - нет... Вопрос об идеальной архитектуре я бы оставил открытой, ибо в какой-то момент вы упретесь в Парето-оптимальность и сможете только менять одни недостатки на другие...
Нет, нет, и еще раз нет! Архитектура - это искусство выстраивания системы сейчас под требования, которые в моменте не предъявляются, не осознаются, и возможно даже не существуют. Проектирование системы под известные требования - это инженерия.
Еще раз повторяю пример, который я привожу разработчикам. К вам приходит молодой человек увлекающийся конным спортом с требованием спроектировать загородный домик с конюшней как можно ближе, чтобы утром выезжать в поле на коне. Инженер вполне может под эти требования сделать конюшню на первом этаже, а жилые помещения на втором, при условии что толщина стен рассчитана на непромерзание зимой, а стропила - на ветровую и снеговую нагрузку. Архитектор же из своего опыта и общей эрудиции - понимает что одинокий молодой человек не всегда будет одиноким и молодым. И поэтому сразу ("вотпрямщас") закладывает в конструкцию избыточность, определяя конюшню отдельным строением, и прокладывая к ней удобную дорожку.
Пример плохой архитектуры - это трущобы какого-нибудь мумбая или сан-паоло. При любом изменении обстановки - они подлежат сносу (если не рухнут сами или сильный дождь не смоет). В противовес этому, примеры хорошей архитектуры - например, дворцовые комплексы, продолжают использоваться даже сейчас (хотя функцию "родового гнезда" или "цитадели знати" уже давно не выполняют).
Другой пример хорошей архитектуры - это человек. У вас достаточно точек гибкости в скелете, чтобы вы могли достать рукой до любого места тела (хотя и с разной степенью удобства). Если бы это было не так - можно было умереть загнав себе небольшую занозу и не имея возможности ее вытащить, и далее сепсис и проч... С другой стороны - в отличие от бесконечно гибкого осьминога - вы достаточно жестки чтобы жить на суше, переносить достаточно тяжелые предметы, манипулировать инструментами. Хотя при рождении, когда задачей является спать и есть мамкину грудь - важность этого функционала совершенно не очевидна.
Сухой итог - архитектура это действительно компромисс. Компромисс между сложностью системы и ее возможностью адаптироваться к неизвестному будущему. Работа архитектора - не сводится к подбору компонентов под требования (хотя и это тоже надо делать). Настоящая работа архитектора (его насмотренность, опыт в отрасли и т.д.) - это сказать вам СЕЙЧАС как надо сделать, чтобы ПОТОМ каждый раз оказывалось: "...могла ли природа предполагать что нам понадобятся очки? А как удачно расположены наши уши!...". То есть, внешний мир изменяясь предъявляет новые требования к вашей системе - и внезапно оказывается что относительно небольшой кровью она может к ним адаптироваться. А у конкурента, который строил как лачуги в мумбае - нет!...
Вы всегда можете увеличить размерность пространства - и там задать какую хотите метрику чтобы что угодно оказалось рядом, или наоборот далеко. Я нахожу в этой работе известные пересечения с классической теорией Вапника-Червоненкиса. В пространстве достаточной размерности, по нескольким примерам вы (статистически) всегда можете провести гиперплоскость которая "достаточно хорошо" разделит примеры на два класса. Свойство выпуклости может оказаться интересным дополнением, потому что В&Ч дают скорее верхнюю границу для количества примеров. Реальные сетки успешно учатся на много меньшем (порядки) размере данных. Выпуклость хорошо объясняет - почему...
Соглашусь. Это два разных инженерных решения. Но я не знаю, какое из них проще в реализации. Камера высокого разрешения позволяет легко находить цели, но чтобы прицелиться - вам нужна точная механика (я не уверен что простые авиамодельные сервы, например, подойдут). Скорее всего, придется городить обратную связь по положению - или с камеры по положению пятна, или с зеркал.
Решение с вращающимися зеркалами крайне простое механически (обороты относительно невелики - сотни оборотов в минуту). Подшипники при такой нагрузке могут работать десятки тысяч часов - доказано компьютерными вентиляторами. Нет необходимости в обратной связи по положению - зондирующий луч гарантированно идет по той же траектории что и боевой: если вы стреляете с одинаковой задержкой (T1, T2) - то в каждом цикле попадаете в одно и то же место. Но придется повозиться с детекцией комара в модулированном отраженном сигнале.
Дальше, наверное, только решение конструктора - с чем он предпочитает бороться. Я, например, больше боюсь безлюфтовой механики и точных приводов с обратной связью...
А кто говорит что лазер должен работать на 100% мощности постоянно ? Ток же можно регулировать через голову... Работает голова на 5 или 10 процентах мощности в зондирующем режиме. При обнаружении комара, он берется на сопровождение на проходе и вычисляется момент выдачи импульса на поражение на следующем проходе. А зеркала вращаются с постоянной скоростью и непрерывно - самый лучший режим для механики, никаких переменных нагрузок...
Если мы разворачиваем луч вращающимися зеркалами - то при постоянной скорости вращения нам надо только датчик который постоянно и предсказуемо дает один импульс на оборот на каждом зеркале. Запустив таймер в микроконтроллере по фронту этого импульса - мы в каждый момент времени будем знать углы поворота зеркал относительно реперной точки. Таким образом, координата комара будет задана двумя временами (T1, T2). И нам, в целом, даже не очень интересно переводить это через скорости вращения зеркал в более привычные углы сферической системы. Можно так и рассчитывать в системе (T1, T2) - потому что на следующем сканировании мы будем по комару производить боевую работу в момент (T1+t1, T2+t2), где (t1, t2) вычисленный вектор (в тех же координатах) видимого углового перемещения комара из предыдущих наблюдений. А фотодиод скорее всего смотрит в те же самые линзы (и тогда он гарантированно смотрит по тем же координатам), либо вообще с широким углом зрения (нам важно поймать модуляцию лазерного луча - длина волны известна - комариными крыльями на частоте 200-600 гц). Если поймали модулированный сигнал - значит лазер прямо сейчас светит на комара.
Камера высокого разрешения не нужна. Комар детектируется по модуляции отраженного излучения взмахами крыльев - достаточно фотодиода и полосового фильтра (аналогового, цифрового - уже неважно). Вы стреляете по любой цели которая а) модулирует отраженный свет в диапазоне 200-600 Гц и б) Попадает в разрешенный диапазон угловых скоростей (чтобы не лупить почем зря по какой-нибудь волосинке которую треплет сквозняк из окна). Разумеется, при этом исключается атака стационарных комаров - но вроде не должно быть проблемой...
Кстати да - классическая задача радиолокации "сопровождение на проходе". Даже несколько проще, потому что с одним излучателем нас не интересует в разумных пределах расстояние до цели - задача двумерная в сферичеких координатах. Каждый проход вычисляются корреляции отметок с нескольких предыдущих, определяется вектор движения цели, и на следующем проходе включается (с гораздо меньшими допусками!) боевой режим.
А эхолокация тоже прикольно!
А кто мешает поставить один главный блок и два-три вспомогательных по углам комнаты ? Тогда мощность единичного излучателя упадет в те же два-три раза. Основной блок выполняет сканирование объема лазером на низкой мощности и ловит модуляцию отраженного излучения в частотном диапазоне взмахов крыльев насекомого характерного размера. Выбрав цель, базовый модуль берет ее на сопровождение в непрерывном режиме, и сообщает об этом вспомогательным модулям. Те просто наводятся на самое яркое пятно в заданном секторе и сопровождают его. Когда все три устройства вышли на режим сопровождения, дается импульс. При этом на цели импульсы складываются (и это единственное место в пространстве где они сложившись - опасны).
Кроме того, требование "перемещение не быстрее 1 м/c" намекает что уничтожение комара будет происходить не миллисекундными импульсами, а скорее всего на относительно низкой мощности и долго. И я бы не стал жечь крылья. Вполне достаточно нанести существенные повреждения ногам/хоботку/телу (а они прекрасно поглощают излучение, и в силу геометрии не смогут сбросить энергию в массивную тушку) - так что у комара возникнет масса других неотложных дел, чтобы он прекратил приставать к людям...
Дурацкая еще идея (но это надо считать) - вообще делать устройство без следящей системы. Просто вращающиеся зеркала и механическая развертка в двух плоскостях. Лазер в дежурном режиме работает на малой мощности и запоминает участки на которых возвратное излучение модулировалось крыльями насекомых. На следующем сканировании - в этих участках (+-допуск по обеим координатам) дается боевой импульс. Если повезло - накрыли. Не повезло - значит не повезло: у нас нет задачи снять комара с воздуха первым же выстрелом. Пусть летает по комнате дальше - поймаем его на следующем цикле сканирования, или через один. Более того, нам не надо даже взрывать его изнутри одним импульсом - достаточно просто наносить какие-то повреждения при попадании. Если мы обеспечиваем сканирование хотя бы с частотой 10-15 герц по объему - через 5-10 секунд комар забудет что он сюда прилетел кушать (или ему будет нечем...).
Да, но у компьютера нет рук, и он сам никогда не играл... Но посмотрим - может быть действительно если обучить его на многих партиях и многих исполнениях, он сможет чисто на выявленных закономерностях "сделать похоже"...
Фортепиано - чуть ли не единственный музыкальный инструмент игра на котором гарантированно не требует каких-либо особых навыков или таланта. Нажми на кнопку - получишь результат. Понятно дело, что виртуозно играть на фортепиано дано немногим. Но опыт имущих классов российской (и не только) империи доказывает - любой аристократ (т.е. даже мозги в голове не гарантируются) при правильной дрессировке преподавателем и родителями может средне-паршиво играть на фортепиано. Там это было совершенно массово, и в обязательном порядке...
Ну, во-первых фактура для диктанта выбирается такая, чтобы средний ученик музшколы ее смог записать. :-) Во-вторых, мне все-таки кажется что учащийся муз.школы дошедший до этого момента - уже имеет достаточную практику игры на инструменте, и пишет не "что слышу, то пишу", а прикидывает как бы он это сыграл - и на этой основе "как бы я это записал чтобы потом сыграть". Если же диктант проводится на тему "Савка и Гришка сделали дуду..." - то это понятно любой кого жизнь приложила об музыкальную школу запишет хоть на слух, хоть по памяти, хоть вверх ногами, хоть задом наперед...
Вот вы убейте меня - но я не верю в то, что можно из звукового файла вернуть обратно нотную запись (если это не чижик-пыжик одной рукой, и мы не читерим распознавая произведение и потом вытаскивая из запазухи честно спиратченые ноты...). Ноты это же не просто информация о том, в какой момент какую клавишу нажали! Это же еще и момент когда ее отпустили (а это пересекается с педалью!). Информацию о многих голосах в одной руке (которая в оригинале передавалась лигами) из звука не восстановить - там вообще неизвестно каким пальцем какой руки ноту брали. Изменения ритма в одном такте (см Таривердиева, например) - откуда оно поймет ?! Плюс живой музыкант не играет как метроном или музыкальная табакерка - на записанные инструкции композитора накладывается личная интерпретация. Как они собираются осеивать одно от другого ? А выделить атаки нот - тут ИИ не надо. Товарищ Фурье давно всем объяснил как выделять спектры...
Мне кажется что китайцы или не хотят производить полностью готовые изделия, или не умеют, или просто прикалываются. И это не зависит от цены. Я на примере 3д-принтеров видел: отличный аппарат, хороший корпус, линейные рейльсы (причем, приличного качества), собрано без перекосов, все катается, и... дребезжащий endswitch который не дает ему нормально печатать (исправление стоит ~$2 - меняем на оптический). Или сделать один из проводов до головы на 8см короче остальных чтобы голова не доставала до дальнего угла... Или экструдер который не позволяет разгоняться хорошей кинематике CoreXY. Или кривой софт, который борется с резонансами не на тех частотах где они есть. Парадокс в том, что исправление стоит копейки (а в условиях завода вообще ничего не стоит - пользователь не заметит изменение цены на копейку)...
При этом, то что реально стоит денег (и невозможно сделать на коленке или даже в мастерской) - сделано нормально, вопросов нет. Но положить какашечку на тортик вместо вишенки - как здрасьте... Ментальность один в один с советским велосипедным заводом: и металл годный, и подшипники ГПЗ положили, и седушку кожаную на пружинах сделали - такая красота, что аж глаза режет! Ну давайте хотя бы болты крепления багажника молотком криво забьем.. :-)
Покупать на алике можно и нужно! Просто не надо ждать что вы покупаете готовое изделие... Как в старые добрые советские времена - вы покупаете набор для творчества! В этом наборе вы найдете кучу добротных компонентов, из которых сможете с небольшими услиями собрать именно то, что вам нужно. Ну а то что не с той стороны отверстия насверлили - это не беда. Когда мне, пацану, купили первый взрослый велосипед - первое что мы сделали с отцом - это его полностью разобрали, вымыли песок из подшипников, прошли метчиком резьбы куда винты забивали молотком, выпрямили держатели крыльев - и он был огонь-машина! А если вы хотите просто отдать денег, включить и поехать, то это всякие буржуйские боши-сименсы. Эти, дай им волю, и еду за вас есть будут...
А почему вы считаете, что чтение и разбор кода после LLM займут сильно меньше времени, чем просто его реализация ? В современных фреймворках "тупая" часть тестирования (моки, ассерты) уже реализована: знай себе инициализируй объекты да проверяй результат... Еще раз - я не против ИИ помогающего писать тесты. Я против ИИ, которому ставят KPI по покрытию (и отбирают тесты целенаправленно на увеличение покрытия). Я (возможно с развитием ИИ это изменится) стою на том, что happy-path тесты должен писать разработчик (потому что ИИ понятия не имеет о бизнес-контексте). А вот анализ покрытия и идентификацию бизнес-кейсов которые не покрыты текущими тестами - вполне можно доверить ИИ. Но эти кейсы должен глазами посмотреть разработчик (т.е. они должны быть сгенерированы в человеко-читаемом виде!), возможно их отредактировать - и потом уже пусть ИИ их реализует (если может). А когда мы показываем человеку PR в котором уже сгенерирован десяток тестов - то или теперь ему придется восстанавливать по коду - какие бизнес-кейсы имелись в виду (и почему), или человек просто перекрестится и нажмет 'Approve' не вдаваясь в подробности...
На самом деле, есть два существенно разных сценария. Вариант 1: перед нами некое легаси, которое надо перетащить на новую версию фреймворка, или запихнуть в облако, или что-то там еще. Мы знаем что оно сейчас работает - это подтверждается практикой. Однако, как во всяком легаси - часть тестов сломана, часть закомментирована, и уже никто не знает почему. Если мы хотим прибить к столу текущий функционал и убедиться что мы его не сломаем в процессе миграции - наверное робот - лучший вариант. Приколотит так что потом зубами не оторвешь. :-)
Если же у нас Вариант 2: идет итерация разработки - то я с вами согласен: инструктировать LLM написать тест который "builds and passes" на непроверенный код - это только создавать себе иллюзию тестирования. Я так в одном проекте видел сервис с зелеными тестами, который в принципе не запускался (функции взаимодействия с БД дописать забыли - но с моками-то все было в порядке!)...