"Какая прелесть!" (С). Хорошо работать в налоговой и не знать о том, каким местом она повернута к налогоплательщику. Как все прочие государственные органы - у налоговой есть KPI по сбору налогов (и штрафов). И начальство уже лет 10 не интересуется тем, как районная налоговая этот план выполняет. Ну то есть нет - вообще-то лучше чтобы и план выполнили, и закон не нарушили, и с налогоплательщиком были вежливы. Но если план горит - то становится можно все:
Списать левым решением нарисованную недоимку, а потом волокитить процесс возврата. А в конце предложить зачесть деньги в счет будущих налоговых обязательств (ну или сейчас - просто положить на единый счет полежать)...
Заставить пользователя региональной налоговой льготы платить федеральную (не льготную ставку) налога УСН. Знаете как ? Каждый месяц трахать всех контрагентов этого льготника предоставлением документов связанных с платежами в адрес льготника по списку: договор, счета, подтверждения оплаты, путевые листы, акты ввода в эксплуатацию основных средств... (список стандартный и очень длинный - да вы наверное и сами знаете). В результате, клиенты приходят к льготнику и говорят что повесят его на заборе (или как минимум разорвут все договора), если он еще раз сдаст "льготную" декларацию по УСН со своим видом деятельности...
...и таких приколов любой предприниматель/собственник/директор вам назовет вагон и маленькую тележку.
А все почему ? А потому что отсутствие сменяемости власти, отсутствие разделения властей (судебная власть де-факто подчинена исполнительной), и принцип НОНД в судах (нет оснований не доверять должностному лицу при исполнении служебных обязанностей) - приводят к деградации чего угодно! :-(
Да нет же! Генерация онтологии через /init - вполне годная вещь! Поймите, агент так устроен что он будет делать дискавери в пустом контексте. И на это дискавери он потратит очень ценные токены в начале контекста. У него начало контекста будет забито разными тул-коллами, причем часть файлов ему нафиг не нужна для работы - но он прочитал и развидеть уже не может. А вы через /init делаете чек-поинт дискавери, и при последующих запусках он СРАЗУ считает это чекпоинт, и будет тратить контекст на задачу. Это как минимум - большая экономия токенов (ибо результат дискавери будет переиспользован столько раз, сколько вы сбросите контекст)
Я уж не говорю, что вы дискавери можете хорошо провести дорогой моделью (например Opus), а потом результат использовать дешевыми моделями. Которые в принципе не способны на качественный дискавери - и вместо этого нафантазируют себе всякое, а потом пойдут на основании этого чего-то править (тот же Haiku)...
Так что нет - онтология при реальной работе важна и нужна. Внимательно посмотреть и почистить после автогенерации - конечно нужно. Но даже автоматическая - сильно лучше чем отсутствие таковой (в реальной жизни, не в исследовании!).
Ну да, беда таких исследований - они не объясняют понятным языком границу применимости. В результате - народ воспринимает это как инструкцию "не писать AGENTS.md". :-(
Я не знаю как они делали это исследование, но это прямо противоречит моим прямым наблюдениям. Контекст - среднего размера Java-проект в корпоративной среде. Без заранее собранной отнологии проекта - любая задача начинается: "ах, давайте посмотрим на pom.xml; ах - давайте посмотрим примеры контроллеров... нет давайте посмотрим еще больше контроллеров чтобы понять эндпоинты; теперь давайте посмотрим бизнес-логику... нет давайте посмотрим больше бизнес логики... а еще посмотрим DTO" - и так уже бОльшая часть контекста кончилась. После появления файла онтологии - агент сразу идет в ту часть проекта, куда ему положено было бы идти - и там читает файлы для конкретной задачи.
А еще - если у вас микросервисы, то вы должны дать агенту понимание что существует часть проекта вне его контроля, но с которой он взаимодействует. А еще - не дай бог в вашей корпоративной структуре есть разнообразные центры компетенций, которые вас снабжают шаблонами инфраструктуры и спринг-бут стартерами (которые агент в глаза не видел, и даже не подозревает об их существовании).
В общем, это исследование - из серии "аэродинамики ЦАГИ после длительных продувок установили, что майский жук не способен к самостоятельному полету" (C).
Вот у меня ровно ситуация была - что хозяева квартиры были наотрез против кондиционера, даже портативного (типа, проводка не выдержит - а ремонт потом им дорого). Решение - evaporative cooler. Выглядит как напольный кондиционер, испаряет в день ведро воды. Открываем настежь окна, направляем поток влажного прохладного воздуха с кулера на себя, и так живем. Расход электроэнергии - минимальный (там внутри помпа как в аквариуме, и вентилятор - все вместе ватт 30-40 потребляет). Но рекомендуется иметь обратный осмос - ибо на водопроводной воде это все будет постепенно зарастать водным камнем, в порах которого зародится примитивная жизнь - и все это вскоре запахнет болотом...
Ну так и в городе на машине какой-то шанс убиться есть. Был случай - мужик остановился на светофоре на красный, сзади его догнал рейсовый ПАЗ груженый пассажирами. По словам водителя автобуса - поймал зайчик с бокового зеркала, через секунду ощутил легкий удар. По факту, смял жопу остановившемуся легковому авто. Водитель легковушки без повреждений, пожилая пенсионерка на заднем сидении - скончалась. Однако, вероятности ниже какой-то мы отбрасываем и при принятии решения - не учитываем. Иначе можно целый год дома сидеть, потому что даже летом есть какая-то вероятность получить по башке сосулькой с крыши...
Ну самолет - понятное дело. Потому что в машине ты будешь часов восемь играть в игры с теорией вероятности (практически все время поездки), а в самолете - все те же 40 минут за полет. Но это не потому что самолет безопаснее автомобиля (я подозреваю что пока автомобиль и самолет делаются примерно из одинаковых материалов и на одном и том же уровне технологии - их "естественная" опасность плюс-минус одинаковая). Просто разная продолжительность опасных участков. Соответственно, летать на работу и домой на вертолете внутри города я бы никому не советовал - даже если на это есть деньги! Ибо рулетка...
Ну и вишенка на торте - если считать пассажиро-километрами, то очень безопасны космические полеты на МКС. Отдельно взятый космонавт за сутки накручивает на орбите близко к 700 тыс.км и ничего ему не делается! Однако, умом мы понимаем что эта статистика даже близко не отражает реальные риски этой работы...
Я предложил бы другой подход к статистике, потому что пассажиро-километры дают некорректную картину. Надо считать на время проведенной в потенциально опасной ситуации. Если вы, например, накручиваете тысячи километров по городу (с ограничением 40-50-60 км/ч) - то несмотря на километраж, риск умереть в автокатастрофе для вас практически не растет. Если же вы к тому каждый день 60 минут проводите на трассе Тюмень-Омск (aka "М51 - дорога смерти") - то вот эти 60 минут реально влияют на вероятность убиться насмерть в дороге.
Аналогично, у рейсового самолета - реально опасны 15-20 минут взлета, и 20-30 минут захода на посадку. Все остальное время, когда он пилит ровно на эшелоне (хоть 30 минут, хоть 6 часов) - не влияет на безопасность примерно никак. А поскольку обычно самолеты на малые расстояния не летают - то за 2-4-6 часов ровного полета набегает много пассажиро-километров которые в статистике делают полеты чрезвычайно безопасным занятием. А если вы отнесете жертвы только к потенциально опасным периодам полета - картина будет совершенно другой.
Если вы хотите посмотреть на безопасность полета как такового - посмотрите на вертолетчиков. Они летают много, но преимущественно в режиме "взлеты-посадки". И бьются как не в себя! У знакомого с выпуска (еще времен СССР) - очень мало кто долетал на вертолетах до пенсии. Или побились насмерть, или ушли после серьезной предпосылки - решили дальше не испытывать судьбу.
Э-э, сказал бы я что основная функция MEL - не обозначить дефекты с которыми можно выпустить борт в воздух, а явное указание альтернативных процедур и ограничений которые позволяют выполнить полет с дефектом и допустимым уровнем безопасности.
В принципе, такие (или похожие по духу) системы применяются во многих отраслях промышленности ("отписывание дефектов/замечаний"). Но правда и в том, что авиация наверное самое массовое место где такое есть, и где это наиболее регламентировано и формализовано. В других отраслях во многих случаях приходится полагаться на экспертное мнение или комиссию, которая принимает решение по замечанию или дефекту.
Да блин! ИИ агент через браузер сам зайдет на сайт, сам сделает скриншоты, сам передаст в другую сетку для перерисовки... Неужели вы не видите противоречия в том, что пишете: ценность заключается в подборке, методологической логике, упаковке - а защищаетесь вы от сохранения картинки на диск ? Не хочу сказать плохого - но это какая-то стандартная странность инженеров: решается не та проблема которая существует, а та - которую легче решить...
Как говорится - эту бы энергию, да в мирных бы целях!... Ладно еще столько сил класть на защиту изображений до того как появились нейросетки - но сейчас?!. Делается скриншот, специально обученной модели говорится нарисовать похоже - и вот у вас в руках то же самое без водяных знаков и в высоком разрешении..
Я уж не говорю, что 99.9(9)% контента на ваших картах неросетками же и сгенерированы. Выглядит так, что вы сами себе успешно придумали проблему, и успешно ее решили. Это (разминка для ума с подписями устройств, canvas, и проч.) лучше чем тупо залипать в шортсах - но хуже по сравнению, скажем, с прогулкой на велосипеде (или на лыжах)...
Я вас спрошу: а вы готовы передать ИИ ответственность за ваш прод ? В смысле - если ваш прод упадет, то вы не будете орать на своих девелоперов: "А ну быстро все починили!", а будете промптить ИИ - и если он не работает, то писать в OpenAI, Anthropic и прочее спортлото ?
Если готовы - тогда флаг вам в руки, и наименования переменных не имеют значения, делайте что хотите!
Если не готовы - тогда нужно сделать так, чтобы команда разработки продолжала быть способной разбираться в коде и чинить его. А это значит - вертайте обратно правильную архитектуру, консистентные наименования переменных, и так далее...
Если уж вы настаиваете на буквах как основе - то обратите внимание, что информационная ценность букв разная. Дл прмр т прдлжн в щ мжт пнть. А эо уе я и!
"Так дело не пойдет..." (C). Сходу проблема заключается в том, что у вас марковская цепь поедает символическую запись языка (буквы). Нам может это казаться странным (особенно при чтении текста, который кажется из букв и состоит) - но мы ни разу не оперируем внутри мозга буквами. Мы оперируем "понятиями". Кто освоил скорочтение - тот не даст соврать - при чтении переносит сразу образ слова с бумаги и ассоциирует его с понятием - не разбирая на буквы и слоги.
Вангую, токенизацию и векторное пространство не зря придумали. Без эквивалентного механизма ассоциации понятий - ничего путного не выходе не будет. Ибо как она ела буквы и их сочетания - так и будет их воспроизводить. Без семантики...
"Если вы узнали о проекте только в момент получения RFP (конкурсной документации) - значит вы плохо коммуницировали с клиентом последние 6 месяцев" (C)
Практически не имеет смысла делать проект в ситуации, когда клиент разослал свое ТЗ в несколько компаний и будет выбирать по цене (точнее - дожимать нормальных исполнителей до самой низкой цены на рынке). Нормальный проект - это когда вы с клиентом поддерживаете отношения, участвуете в выработке технического решения, стека, договариваетесь о стоимости, а ТЗ и процедура закупки - чисто формальное мероприятие.
Нет, вру - есть один вариант когда делать стоит: если вы уверены что хотите работать дальше с этим клиентом, и вам надо туда зайти. Тогда первый проект вы делаете за любые деньги чтобы показать свои компетенции. А разницу между себестоимостью и фактическими издержками этого проекта списываете на маркетинг (потому что это он самый и есть).
Для тех, кто в школе не учил химию (чисто на всякий случай) - реактивный двигатель использует даровый окислитель из атмосферы. В камере сгорания к нему добавляется топливо - причем используется только часть кислорода на окисление. То есть - у нас выходит за турбину газ, в котором еще есть кислород (а если двигатель двухконтурный - то там часть воздуха через вентилятор идет прямо на выход минуя камеру сгорания для повышения массового расхода и КПД - то есть смесь прямо-таки распирает от дармового окислителя). И если в сопло впрыснуть еще горючего - то можно израсходовать еще кислорода из воздуха и получить неплохую прибавку к тяге (за счет дикого расхода горючего - потому что сжигаем мы его не там где следовало бы).
Перекись водорода - сама по себе жуткий окислитель. Подводники на субмаринах доатомной эпохи не дадут соврать - они такое строили... У некоторых даже плавало... Но от впрыскивания окислителя в уже и так богатую окислителем среду - вам легче не станет. Наоборот, вы скорее всего потеряете температуру и давление - ибо впрыснутую перекись что-то должно греть и испарять. А если вы хотите ее разлагать - то это лучше на катализаторе, или опять же в смеси с горючим жечь...
"Нет смысла объяснять что за дурдом тут творится - поэтому давайте просто напишем: дела идут хорошо" (С).
Автор, если вы не хотите чтобы над вами обидно смеялись - поставьте на вертолет экспериментальную систему огибания рельефа, и успокойтесь. Вы по сюжету один черт не используете ни одного преимущества экраноплана, кроме необычности слова. Или посадите их на скиммер, не шибко расшифровывая что это и откуда.
Давайте обсуждать без висения в воздухе - ибо это уже за пределами! Пусть висит на какой-нибудь воздушной подушке что-ли - "нызенько-нызенько" (C) ? Двигатели на перекиси - это вообще дикая дичь! Нафига в приземной атмосфере реактивный двигатель, причем ущербный ? Ладно в спускаемом аппарате "Союза" - там надо ориентацию поддерживать на гиперзвуке, и в разреженной атмосфере! Но в устройстве предназдаченном для плотных слоев атмосферы - reactional thrusters, и тем более на перекиси (славы конструкторов Ме-163 что-ли захотелось ?!) быть не должно!
Cl/Cd - сиречь "аэродинамическое качество". Но имейте в виду, что Cl/Cd играет только в ровном горизонтальном полете. Если вы хотите уходить с экрана оперативно - вам нужен или запас скорости (что убивает идею экрана - точнее он становится не нужен - вы летите на подъемной силе), или запас тяги с очень быстрой реакцией, чтобы при уходе с экрана заместить упавшую часть подъемной силы тягой двигателей (потому что разогнаться мгновенно все-равно не получится).
Понимаете в чем проблема - в шеринге бытовых вещей и инструментов возникает две проблемы:
От увеличения количества пользователей - спрос не выравнивается настолько, насколько хотелось бы. Какую бы совершенную систему шеригна вы не придумали - перфоратор не будет использоваться минимум 50% времени - потому что ночью сверлить и долбить нельзя (вплоть от штрафа от милиции, и фигала под глазом от благодарных соседей). Соответственно, как пользователь - вы не получите доступ к инструменту именно тогда, когда он больше всего (!) нужен. Шеринговая компания может с этим бороться путем динамического ценнобразования - но теперь как пользователь вы не только не знаете получите вы инструмент или нет - но и сколько это будет стоить!
За чужой инструмент - никто как за свой трястись не будет. В результате, вы как очередной пользователь - либо будете вынуждены брать инструмент в полу-исправном виде, либо не брать вообще.
Как следствие, сервисы - очень быстро вместо заработка на шеринге - начинут зарабатывать на штрафах, ловя пользователей на том, что они при начале и конце шеринга не зафиксировали все царапки инструмента. Я уж не говорю, что дрель можеть быть блестящей с виду, но не сверлить...
Ну и нахрена оно такое надо ? Купил инструмент - и нехай лежит. Это не хлеб чтобы заплесневеть и зачерстветь за неделю...
"Какая прелесть!" (С). Хорошо работать в налоговой и не знать о том, каким местом она повернута к налогоплательщику. Как все прочие государственные органы - у налоговой есть KPI по сбору налогов (и штрафов). И начальство уже лет 10 не интересуется тем, как районная налоговая этот план выполняет. Ну то есть нет - вообще-то лучше чтобы и план выполнили, и закон не нарушили, и с налогоплательщиком были вежливы. Но если план горит - то становится можно все:
Списать левым решением нарисованную недоимку, а потом волокитить процесс возврата. А в конце предложить зачесть деньги в счет будущих налоговых обязательств (ну или сейчас - просто положить на единый счет полежать)...
Заставить пользователя региональной налоговой льготы платить федеральную (не льготную ставку) налога УСН. Знаете как ? Каждый месяц трахать всех контрагентов этого льготника предоставлением документов связанных с платежами в адрес льготника по списку: договор, счета, подтверждения оплаты, путевые листы, акты ввода в эксплуатацию основных средств... (список стандартный и очень длинный - да вы наверное и сами знаете). В результате, клиенты приходят к льготнику и говорят что повесят его на заборе (или как минимум разорвут все договора), если он еще раз сдаст "льготную" декларацию по УСН со своим видом деятельности...
...и таких приколов любой предприниматель/собственник/директор вам назовет вагон и маленькую тележку.
А все почему ? А потому что отсутствие сменяемости власти, отсутствие разделения властей (судебная власть де-факто подчинена исполнительной), и принцип НОНД в судах (нет оснований не доверять должностному лицу при исполнении служебных обязанностей) - приводят к деградации чего угодно! :-(
Да нет же! Генерация онтологии через /init - вполне годная вещь! Поймите, агент так устроен что он будет делать дискавери в пустом контексте. И на это дискавери он потратит очень ценные токены в начале контекста. У него начало контекста будет забито разными тул-коллами, причем часть файлов ему нафиг не нужна для работы - но он прочитал и развидеть уже не может. А вы через /init делаете чек-поинт дискавери, и при последующих запусках он СРАЗУ считает это чекпоинт, и будет тратить контекст на задачу. Это как минимум - большая экономия токенов (ибо результат дискавери будет переиспользован столько раз, сколько вы сбросите контекст)
Я уж не говорю, что вы дискавери можете хорошо провести дорогой моделью (например Opus), а потом результат использовать дешевыми моделями. Которые в принципе не способны на качественный дискавери - и вместо этого нафантазируют себе всякое, а потом пойдут на основании этого чего-то править (тот же Haiku)...
Так что нет - онтология при реальной работе важна и нужна. Внимательно посмотреть и почистить после автогенерации - конечно нужно. Но даже автоматическая - сильно лучше чем отсутствие таковой (в реальной жизни, не в исследовании!).
Ну да, беда таких исследований - они не объясняют понятным языком границу применимости. В результате - народ воспринимает это как инструкцию "не писать AGENTS.md". :-(
Я не знаю как они делали это исследование, но это прямо противоречит моим прямым наблюдениям. Контекст - среднего размера Java-проект в корпоративной среде. Без заранее собранной отнологии проекта - любая задача начинается: "ах, давайте посмотрим на pom.xml; ах - давайте посмотрим примеры контроллеров... нет давайте посмотрим еще больше контроллеров чтобы понять эндпоинты; теперь давайте посмотрим бизнес-логику... нет давайте посмотрим больше бизнес логики... а еще посмотрим DTO" - и так уже бОльшая часть контекста кончилась. После появления файла онтологии - агент сразу идет в ту часть проекта, куда ему положено было бы идти - и там читает файлы для конкретной задачи.
А еще - если у вас микросервисы, то вы должны дать агенту понимание что существует часть проекта вне его контроля, но с которой он взаимодействует. А еще - не дай бог в вашей корпоративной структуре есть разнообразные центры компетенций, которые вас снабжают шаблонами инфраструктуры и спринг-бут стартерами (которые агент в глаза не видел, и даже не подозревает об их существовании).
В общем, это исследование - из серии "аэродинамики ЦАГИ после длительных продувок установили, что майский жук не способен к самостоятельному полету" (C).
Вот у меня ровно ситуация была - что хозяева квартиры были наотрез против кондиционера, даже портативного (типа, проводка не выдержит - а ремонт потом им дорого). Решение - evaporative cooler. Выглядит как напольный кондиционер, испаряет в день ведро воды. Открываем настежь окна, направляем поток влажного прохладного воздуха с кулера на себя, и так живем. Расход электроэнергии - минимальный (там внутри помпа как в аквариуме, и вентилятор - все вместе ватт 30-40 потребляет). Но рекомендуется иметь обратный осмос - ибо на водопроводной воде это все будет постепенно зарастать водным камнем, в порах которого зародится примитивная жизнь - и все это вскоре запахнет болотом...
Ну так и в городе на машине какой-то шанс убиться есть. Был случай - мужик остановился на светофоре на красный, сзади его догнал рейсовый ПАЗ груженый пассажирами. По словам водителя автобуса - поймал зайчик с бокового зеркала, через секунду ощутил легкий удар. По факту, смял жопу остановившемуся легковому авто. Водитель легковушки без повреждений, пожилая пенсионерка на заднем сидении - скончалась. Однако, вероятности ниже какой-то мы отбрасываем и при принятии решения - не учитываем. Иначе можно целый год дома сидеть, потому что даже летом есть какая-то вероятность получить по башке сосулькой с крыши...
Ну самолет - понятное дело. Потому что в машине ты будешь часов восемь играть в игры с теорией вероятности (практически все время поездки), а в самолете - все те же 40 минут за полет. Но это не потому что самолет безопаснее автомобиля (я подозреваю что пока автомобиль и самолет делаются примерно из одинаковых материалов и на одном и том же уровне технологии - их "естественная" опасность плюс-минус одинаковая). Просто разная продолжительность опасных участков. Соответственно, летать на работу и домой на вертолете внутри города я бы никому не советовал - даже если на это есть деньги! Ибо рулетка...
Ну и вишенка на торте - если считать пассажиро-километрами, то очень безопасны космические полеты на МКС. Отдельно взятый космонавт за сутки накручивает на орбите близко к 700 тыс.км и ничего ему не делается! Однако, умом мы понимаем что эта статистика даже близко не отражает реальные риски этой работы...
Я предложил бы другой подход к статистике, потому что пассажиро-километры дают некорректную картину. Надо считать на время проведенной в потенциально опасной ситуации. Если вы, например, накручиваете тысячи километров по городу (с ограничением 40-50-60 км/ч) - то несмотря на километраж, риск умереть в автокатастрофе для вас практически не растет. Если же вы к тому каждый день 60 минут проводите на трассе Тюмень-Омск (aka "М51 - дорога смерти") - то вот эти 60 минут реально влияют на вероятность убиться насмерть в дороге.
Аналогично, у рейсового самолета - реально опасны 15-20 минут взлета, и 20-30 минут захода на посадку. Все остальное время, когда он пилит ровно на эшелоне (хоть 30 минут, хоть 6 часов) - не влияет на безопасность примерно никак. А поскольку обычно самолеты на малые расстояния не летают - то за 2-4-6 часов ровного полета набегает много пассажиро-километров которые в статистике делают полеты чрезвычайно безопасным занятием. А если вы отнесете жертвы только к потенциально опасным периодам полета - картина будет совершенно другой.
Если вы хотите посмотреть на безопасность полета как такового - посмотрите на вертолетчиков. Они летают много, но преимущественно в режиме "взлеты-посадки". И бьются как не в себя! У знакомого с выпуска (еще времен СССР) - очень мало кто долетал на вертолетах до пенсии. Или побились насмерть, или ушли после серьезной предпосылки - решили дальше не испытывать судьбу.
Э-э, сказал бы я что основная функция MEL - не обозначить дефекты с которыми можно выпустить борт в воздух, а явное указание альтернативных процедур и ограничений которые позволяют выполнить полет с дефектом и допустимым уровнем безопасности.
В принципе, такие (или похожие по духу) системы применяются во многих отраслях промышленности ("отписывание дефектов/замечаний"). Но правда и в том, что авиация наверное самое массовое место где такое есть, и где это наиболее регламентировано и формализовано. В других отраслях во многих случаях приходится полагаться на экспертное мнение или комиссию, которая принимает решение по замечанию или дефекту.
Да блин! ИИ агент через браузер сам зайдет на сайт, сам сделает скриншоты, сам передаст в другую сетку для перерисовки... Неужели вы не видите противоречия в том, что пишете: ценность заключается в подборке, методологической логике, упаковке - а защищаетесь вы от сохранения картинки на диск ? Не хочу сказать плохого - но это какая-то стандартная странность инженеров: решается не та проблема которая существует, а та - которую легче решить...
Как говорится - эту бы энергию, да в мирных бы целях!... Ладно еще столько сил класть на защиту изображений до того как появились нейросетки - но сейчас?!. Делается скриншот, специально обученной модели говорится нарисовать похоже - и вот у вас в руках то же самое без водяных знаков и в высоком разрешении..
Я уж не говорю, что 99.9(9)% контента на ваших картах неросетками же и сгенерированы. Выглядит так, что вы сами себе успешно придумали проблему, и успешно ее решили. Это (разминка для ума с подписями устройств, canvas, и проч.) лучше чем тупо залипать в шортсах - но хуже по сравнению, скажем, с прогулкой на велосипеде (или на лыжах)...
Я вас спрошу: а вы готовы передать ИИ ответственность за ваш прод ? В смысле - если ваш прод упадет, то вы не будете орать на своих девелоперов: "А ну быстро все починили!", а будете промптить ИИ - и если он не работает, то писать в OpenAI, Anthropic и прочее спортлото ?
Если готовы - тогда флаг вам в руки, и наименования переменных не имеют значения, делайте что хотите!
Если не готовы - тогда нужно сделать так, чтобы команда разработки продолжала быть способной разбираться в коде и чинить его. А это значит - вертайте обратно правильную архитектуру, консистентные наименования переменных, и так далее...
Если уж вы настаиваете на буквах как основе - то обратите внимание, что информационная ценность букв разная. Дл прмр т прдлжн в щ мжт пнть. А эо уе я и!
"Так дело не пойдет..." (C). Сходу проблема заключается в том, что у вас марковская цепь поедает символическую запись языка (буквы). Нам может это казаться странным (особенно при чтении текста, который кажется из букв и состоит) - но мы ни разу не оперируем внутри мозга буквами. Мы оперируем "понятиями". Кто освоил скорочтение - тот не даст соврать - при чтении переносит сразу образ слова с бумаги и ассоциирует его с понятием - не разбирая на буквы и слоги.
Вангую, токенизацию и векторное пространство не зря придумали. Без эквивалентного механизма ассоциации понятий - ничего путного не выходе не будет. Ибо как она ела буквы и их сочетания - так и будет их воспроизводить. Без семантики...
"Если вы узнали о проекте только в момент получения RFP (конкурсной документации) - значит вы плохо коммуницировали с клиентом последние 6 месяцев" (C)
Практически не имеет смысла делать проект в ситуации, когда клиент разослал свое ТЗ в несколько компаний и будет выбирать по цене (точнее - дожимать нормальных исполнителей до самой низкой цены на рынке). Нормальный проект - это когда вы с клиентом поддерживаете отношения, участвуете в выработке технического решения, стека, договариваетесь о стоимости, а ТЗ и процедура закупки - чисто формальное мероприятие.
Нет, вру - есть один вариант когда делать стоит: если вы уверены что хотите работать дальше с этим клиентом, и вам надо туда зайти. Тогда первый проект вы делаете за любые деньги чтобы показать свои компетенции. А разницу между себестоимостью и фактическими издержками этого проекта списываете на маркетинг (потому что это он самый и есть).
Для тех, кто в школе не учил химию (чисто на всякий случай) - реактивный двигатель использует даровый окислитель из атмосферы. В камере сгорания к нему добавляется топливо - причем используется только часть кислорода на окисление. То есть - у нас выходит за турбину газ, в котором еще есть кислород (а если двигатель двухконтурный - то там часть воздуха через вентилятор идет прямо на выход минуя камеру сгорания для повышения массового расхода и КПД - то есть смесь прямо-таки распирает от дармового окислителя). И если в сопло впрыснуть еще горючего - то можно израсходовать еще кислорода из воздуха и получить неплохую прибавку к тяге (за счет дикого расхода горючего - потому что сжигаем мы его не там где следовало бы).
Перекись водорода - сама по себе жуткий окислитель. Подводники на субмаринах доатомной эпохи не дадут соврать - они такое строили... У некоторых даже плавало... Но от впрыскивания окислителя в уже и так богатую окислителем среду - вам легче не станет. Наоборот, вы скорее всего потеряете температуру и давление - ибо впрыснутую перекись что-то должно греть и испарять. А если вы хотите ее разлагать - то это лучше на катализаторе, или опять же в смеси с горючим жечь...
"Нет смысла объяснять что за дурдом тут творится - поэтому давайте просто напишем: дела идут хорошо" (С).
Автор, если вы не хотите чтобы над вами обидно смеялись - поставьте на вертолет экспериментальную систему огибания рельефа, и успокойтесь. Вы по сюжету один черт не используете ни одного преимущества экраноплана, кроме необычности слова. Или посадите их на скиммер, не шибко расшифровывая что это и откуда.
Давайте обсуждать без висения в воздухе - ибо это уже за пределами! Пусть висит на какой-нибудь воздушной подушке что-ли - "нызенько-нызенько" (C) ? Двигатели на перекиси - это вообще дикая дичь! Нафига в приземной атмосфере реактивный двигатель, причем ущербный ? Ладно в спускаемом аппарате "Союза" - там надо ориентацию поддерживать на гиперзвуке, и в разреженной атмосфере! Но в устройстве предназдаченном для плотных слоев атмосферы - reactional thrusters, и тем более на перекиси (славы конструкторов Ме-163 что-ли захотелось ?!) быть не должно!
Cl/Cd - сиречь "аэродинамическое качество". Но имейте в виду, что Cl/Cd играет только в ровном горизонтальном полете. Если вы хотите уходить с экрана оперативно - вам нужен или запас скорости (что убивает идею экрана - точнее он становится не нужен - вы летите на подъемной силе), или запас тяги с очень быстрой реакцией, чтобы при уходе с экрана заместить упавшую часть подъемной силы тягой двигателей (потому что разогнаться мгновенно все-равно не получится).
Понимаете в чем проблема - в шеринге бытовых вещей и инструментов возникает две проблемы:
От увеличения количества пользователей - спрос не выравнивается настолько, насколько хотелось бы. Какую бы совершенную систему шеригна вы не придумали - перфоратор не будет использоваться минимум 50% времени - потому что ночью сверлить и долбить нельзя (вплоть от штрафа от милиции, и фигала под глазом от благодарных соседей). Соответственно, как пользователь - вы не получите доступ к инструменту именно тогда, когда он больше всего (!) нужен. Шеринговая компания может с этим бороться путем динамического ценнобразования - но теперь как пользователь вы не только не знаете получите вы инструмент или нет - но и сколько это будет стоить!
За чужой инструмент - никто как за свой трястись не будет. В результате, вы как очередной пользователь - либо будете вынуждены брать инструмент в полу-исправном виде, либо не брать вообще.
Как следствие, сервисы - очень быстро вместо заработка на шеринге - начинут зарабатывать на штрафах, ловя пользователей на том, что они при начале и конце шеринга не зафиксировали все царапки инструмента. Я уж не говорю, что дрель можеть быть блестящей с виду, но не сверлить...
Ну и нахрена оно такое надо ? Купил инструмент - и нехай лежит. Это не хлеб чтобы заплесневеть и зачерстветь за неделю...