Vibe coding complex changes in Rust

Всем привет. Снова приветствую вас на очередном стриме по Rust. На этот раз мы займемся чем-то новым. Эм, мы по-прежнему будем использовать Rust. Эм, но мы попробуем заняться программированием, создающим атмосферу. Однако есть одно нюанс: я никогда раньше не занимался программированием с использованием Vibe. Я видел, как это делали другие люди. Я установил Clawed Code и настроил его с использованием определённого репозитория. Эм, и отчасти это потому, что я, э-э, довольно сдержан в отношении большей части нынешнего ажиотажа вокруг ИИ, назовем это хайпом, независимо от того, заслужен он или нет. В частности, у меня есть это... глубоко укоренившееся чувство страха — это не совсем подходящее слово, — но ощущение, что эти модели машинного обучения на самом деле не понимают, что делают, что они на самом деле в чем-то хороши. Они действительно хорошо умеют распознавать закономерности, воспроизводить закономерности, объединять закономерности и, э-э, воспроизводить вещи, которые кажутся логичными и понятными, то есть выглядят разумными, даже без понимания механизмов, происходящих за кулисами. Это значит, что, если бы я попытался угадать, в чём он хорош, то, вероятно, это были бы такие вещи, как написание шаблона WordPress, создание ещё одного приложения командной строки или взаимодействие с AWS SDK или несколькими AWS SDK для настройки параметров между ними. Разработка ботов на основе известных API, когда в интернете существует множество хороших примеров, которые можно собрать воедино, чтобы создать вполне работоспособное приложение. И это может стать довольно сложным делом. Дело не в том, что я считаю, будто они не могут создавать сложные вещи. Я подозреваю, что трудности у них возникают в рассуждениях о таких вещах, как правила заимствования в Rust или такие сложные свойства системы типов, как обратная совместимость этого изменения? Это вещи, которые действительно требуют от вас понимания лежащих в их основе принципов, а не просто умения их воспроизводить (звучит слишком строго), но... где вы можете лишь повторять то, что уже много раз видели в качестве примеров. Эм, но, конечно, это мое личное мнение, но это не значит, что оно истинно. Итак, я хочу провести несколько тестов, чтобы собрать доказательства для себя, используя код, имитирующий атмосферу игры. А это, по сути, научный подход, когда пытаешься доказать свою неправоту, верно? Итак, у меня есть список из четырех различных изменений, которые я хочу внести в эту конкретную библиотеку. Я объясню, что такое библиотека, чуть позже. Эм, и поэтому я постараюсь внести как можно больше из этих четырех изменений в течение следующих, ну, сколько бы часов это ни заняло. Эм, и я просто хочу посмотреть, насколько хорошо с этим справится ИИ Agentic. Например, способна ли она делать то, что, как мне кажется, она не способна или с чем, как я думаю, у нее возникнут трудности, чтобы лучше настроить свой мозг на то, что осуществимо, а что нет. Конечно, следует помнить, что для меня это в новинку. Я раньше не занимался программированием на Vibe. Так что здесь вы услышите мои, так сказать, мои самые первые впечатления о том, насколько хорошо или плохо это работает. А это также означает, что существует множество техник, которые мне неизвестны. Я, я не совсем уж необразованный человек. Ой. Итак, я провел некоторое исследование того, что делают другие люди, чтобы подтолкнуть к созданию генетического ИИ и всего остального. Эм, я не начинаю с того, что даже не знаю, что это такое. Эм, но мне не нравится, что мне будет не хватать многих навыков и пальцев, которые есть у людей, которые много этим занимались до сих пор, в той степени, в которой это возможно, учитывая новизну технологий. Эм, но я предполагаю, что в процессе будет много ситуаций, когда я скажу: «Это не очень хорошо работает», а потом в чате или после видео кто-то другой скажет мне: «О, ты просто сделал это неправильно. Если бы ты использовал другой способ подсказки, всё было бы намного лучше». Так что, возможно, мы проведём второй стрим, где Джон, уже не новичок в этом деле, снова попробует себя в тех вещах, которые, по его словам, у него плохо получались. Эм, отчасти это также связано с тем, что я хочу попытаться сформулировать, что в итоге оказывается сложным, например, определить, что они могут делать хорошо, а с чем у агентного ИИ возникают трудности. Эм, мне тоже очень интересно посмотреть, что здесь скажут в чате. Я предполагаю, что в чате у нас довольно равномерное распределение людей, которые уже много занимались программированием в реальном времени, и тех, кто относится к этому очень скептически, как я, и всех, кто находится между этими крайностями. Итак, мы собираемся совершить это путешествие вместе. Эмм, два организационных момента, прежде чем мы начнём. Во-первых, это мой первый в жизни стрим, спонсированный спонсором. Мне никто не поручал заниматься именно этой темой. Это видео не спонсируется, например, компанией Anthropic или чем-то подобным, но у видео есть спонсор, который просто хочет, чтобы я создавал больше образовательного контента, и он

мне в этом помогает. Подробнее о спонсоре — в конце видео, если вам интересно. Эмм, второе — это ящик, над которым мы будем здесь работать, выбранный полупроизвольно. Я выбрала один вариант, где у меня есть кое-какие планы, и где, как мне кажется, проблемы связаны с теми аспектами, которые я считаю сложными. Итак, прежде чем мы начнём работать с этой библиотекой, я кратко расскажу о ней. И это просто потому, что, я думаю, вам всем потребуется контекст, чтобы понять, почему эти изменения не являются тривиальными. Эм, это на самом деле доклад, который я читал на встрече Rust в Амстердаме два дня назад. Я приведу здесь сокращенную версию этого. Эм, и не стесняйтесь задавать вопросы в чате. Я постараюсь изложить всё достаточно кратко, чтобы вы поняли, какую проблему пытается решить этот ящик. И еще, способ, которым он пытается это решить. Прохладный. Хорошо. Эм, есть ли у вас какие-либо вопросы по поводу подготовки к этому видео, прежде чем я расскажу, что такое Squaba и почему она так называется? Множество людей, которым интересно, как это будет выглядеть. Есть люди, которые относятся к этому с таким же скептицизмом, а есть и те, кто очень воодушевлен. Я буду использовать облачный код. По моим наблюдениям, судя по отзывам местных жителей, это, пожалуй, лучший вариант. Эм, я видел информацию о Gemini, например, о Gemini CLI, это довольно перспективный инструмент, который к тому же может быть дешевле в использовании. Но я хотел выбрать, пожалуй, лучший вариант, даже если он дороже, например, чтобы убедиться, что я не испорчу свои первоначальные впечатления некачественным инструментом. Я не хочу винить инструмент в том, что он плохо сработал. Эм, хорошо, отлично. Итак, скваба. Итак, подготовка к этому такова: на работе нам нужно выполнить множество пространственных вычислений. Пространственная математика — это не технический термин, а скорее математика, описывающая объекты в трёхмерном пространстве. Представьте, что вы видите самолет, летящий в воздухе, и замечаете что-то в окне самолета, и хотите описать, где это что-то находится относительно самолета. Эм, это как раз тот случай, когда нужны трехмерные координаты. Можно подумать о координатах GPS, но если пилот сидит в кресле и говорит: «Вот так», как он сможет передать это в осмысленном виде? И как это перевести в понятный для человека контекст, находящегося на земле, или в GPS-координатах, или в любой другой системе? Это требует преобразования между этими различными системами координат, поскольку вы выполняете математические операции в пространственном пространстве, например, в 3D-пространстве. Весь наш код, по сути, написан на Rust, поэтому я хотел написать этот код на Rust, и в частности, я хотел сделать его типобезопасным. Я хотел убедиться, что если вы создаёте координату, которая на самом деле является просто координатой XYZ, то есть она состоит всего из трёх чисел с плавающей запятой, но если вы создаёте координату в одной системе координат, например, северо-восток, направление по компасу, а затем создаёте другую координату, которая находится в системе координат, используемой пилотом, когда он смотрит в окно, то эти две координаты будут в разных системах координат, они не взаимозаменяемы. Поэтому мы хотим на уровне типов обеспечить их различие. Интересное свойство этого заключается в том, что библиотека Squaba в основном состоит из типов, а не из реализации. Большая часть реализации — это, по сути, алгебраические типы, кванторы и некоторые операции умножения. Эм, и большая часть этого сводится к попытке упаковать это в представление типа, которое сделает его безопасным для использования или, наоборот, затруднит неправильное использование. Эм, по сути, мы пытаемся ответить на вопрос, где находится этот путь, когда вы говорите «этот путь» в трехмерном пространстве. Вам нужно решить две задачи. Один из вопросов — какова ваша система координат? А что это за точка относительно чего? И второй вопрос: как моя система координат соотносится с вашей системой координат? Эм, как же эти два варианта соотносятся друг с другом? А как мне переходить между ними? Итак, сейчас мы проведем здесь упражнение. Где воздушный шар? Итак, допустим, пилот самолета замечает метеорологический зонд за окном под углом 30° вверх от прямо перед собой, примерно в 2 часах езды вправо от своего самолета, на расстоянии около 150 м. Сам самолет летит на северо-северо-восток и набирает высоту под углом 10°. Итак, вы уже видите, что нам нужно кое-что сделать, чтобы объединить эти ракурсы, верно? Потому что если пилот смотрит на 30° вверх, а самолет набирает высоту под углом 10°, то очевидно, что это примерно 40° к земле. Так что, раз уж мы там, что-то уже происходит. Эм, а сам самолет находится по этим конкретным GPS- координатам, которые, как оказалось, расположены над Музеем викингов в Осло, почему бы и нет? Оно же где-то должно быть, правда? И теперь возникает вопрос: где же воздушный шар? Теоретически, у вас достаточно

информации, чтобы вычислить GPS-координаты воздушного шара. Но попробуйте, используя информацию, отображаемую на экране, вычислить эти координаты. Это действительно непросто. А причина в том, что здесь используется множество различных систем координат. Первый тип — это так называемая FRD, или передняя правая нижняя часть, которая описывает положение относительно фюзеляжа самолета, например, оси самолета, проходящие через нижнюю часть фюзеляжа, крылья и/или вдоль фюзеляжа, а не через крылья и вниз по нижней части фюзеляжа. Затем идет северо-восток, то, что мы обычно считаем направлениями по компасу. Итак, на север, восток и вниз. Это три оси данной системы координат. А еще у нас есть WGS84, то есть то, что мы обычно знаем как координаты GPS. Так что это не декартова система координат. В нём нет xyz. Это просто широта, долгота и высота, обозначенные как точка на земной сфере. Поэтому нам нужен какой-то способ связать их между собой. Эм, первая из них — это локальная система координат. Она описывает координаты относительно оси тела какого-либо объекта, например, плоскости. У нас передняя часть опущена, как я только что говорил. Здесь также используются другие системы координат для осей, например, "спереди справа вверх", которая широко применяется в Unity. Итак, здесь оси XYZ: передняя часть — X, правая — Y, а в схеме FRD передняя правая часть — вниз, ось Z — вниз. Таким образом, положительное значение Z находится ниже уровня самолета. В Unity ось Z направлена вверх, в положительном направлении. То есть, сверху вниз или снизу вверх от экрана. Затем у нас есть системы пространственной привязки. Это, по сути, противоположный конец, то есть то, что находится на Земле. Обычно мы подразумеваем географические или геодезические координаты, такие как широта, долгота и высота, например, WGS84. Но вокруг Земли также существуют системы координат XYZ, например, EF (землецентрированная фиксированная система), которая представляет собой декартову систему координат, где ось X проходит от центра Земли через нулевую широту и нулевую долготу. А затем ось Y идет вдоль экваториальной плоскости, но направлена ​​под углом, равным 90 градусам, вдоль экваториальной плоскости. А затем ось Z — это третья ось, которая проходит вверх через полюс, перпендикулярно или, скорее, ортогонально обоим предыдущим углам. А еще у нас есть локальные касательные плоскости. Локальные касательные плоскости — это, например, направления по компасу. Представьте, что это называется локальной касательной плоскостью. Представьте, что вы стоите где-то на Земле, держите компас, и он показывает, что север находится в этом направлении. Если вы посмотрите, куда указывает этот человек, и проследите за его пальцем прямо перед собой, то в итоге получите линию, уходящую в пространство, и то, что вы делаете, — это указываете вдоль локальной касательной плоскости. самолет. Плоскость — это плоская поверхность, похожая на лист бумаги, которая касается плоскости. Таким образом, она едва касается одной точки на Земле, и именно на неё вы и указываете. Поэтому всякий раз, когда мы говорим о направлениях по компасу, это как если бы вы положили в этом месте плоский лист бумаги и затем определяли направления в соответствии с этим листом. И, возможно, очевидно, что если вы находитесь в другой точке земного шара, ваш лист, ваша плоскость, ваш самолет будут расположены под другим углом. Поворот будет другим, потому что север там отличается от севера здесь. Поэтому нам необходимо уметь говорить о различных системах направления на северо-восток, о разных системах компаса в зависимости от того, где мы находимся на Земле. Здесь тоже, как я уже упоминал, северо-восток — распространённый вариант. Таким образом, ось X направлена ​​на север, ось востока — на восток, ось Y — на восток, а ось Z — вниз. Этот термин широко используется в аэрокосмической отрасли, поскольку обычно речь идёт о вещах, находящихся под землёй. Поэтому логичнее располагать положительные z-координаты внизу, поскольку большинство объектов находятся именно там. И вам вряд ли захочется, чтобы большинство ваших координат имели отрицательное число на одной из осей. Между тем, в наземных транспортных средствах чаще используется обозначение "восток - север - вверх", где ось X направлена ​​на восток, ось Y - на север, а ось Z - вверх от земли. Возможно, вас смущает, почему север и восток здесь обозначены в разных направлениях. Это ещё один момент, который создаст сложности. Итак, чтобы всё это соединить, вам нужна пространственная привязка, которая покажет, где именно на Земле вы находитесь. Для определения ориентации в этой точке на Земле необходима касательная плоскость. А затем вам понадобится телесная референтная точка, чтобы иметь возможность говорить о вещах в контексте вашего собственного «я», рассматривая вас как объект в окружающем мире. Оказывается, можно взять любую систему координат XYZ и любую декартову систему координат и перемещаться между ними, просто выполняя вращение и перемещение. Представьте, что я стою здесь, а вы стоите вон там. Если я скажу, что что-то находится именно так, то для того, чтобы получить этот угол относительно вас, мне нужно повернуть это так, чтобы оно находилось там, где находитесь вы. Но если я просто повернусь, то этот вектор все равно будет указывать из того места, где я нахожусь. Поэтому я хочу перевести это туда, где вы находитесь. И теперь всё идёт в правильном направлении. Таким образом, каждое преобразование между двумя системами отсчета, которые являются декартовыми, то есть имеют координаты XYZ, представляет собой вращение плюс перемещение, что математически может быть выражено в виде квиттерианской системы. Это можно рассматривать как своего рода матрицу. Эм, это

работает только в картезианских системах. Таким образом, координаты WGS84, как и координаты GPS, не являются картезианскими. Таким образом, в общем случае, для преобразования между системами координат, позволяющими приблизиться к GPS, необходимо использовать дополнительную систему координат, например, XYC-систему вокруг Земли. А еще есть относительно четко определенная процедура преобразования координат GPS в EIF Хорошо. А еще есть соглашения об использовании осей координат, которые мы пока проигнорируем, поскольку они не имеют особого отношения к тому, что мы собираемся делать. А еще есть подшипники, о которых мы еще поговорим. Но об этом достаточно, пожалуй, и стоит сказать о подшипниках. Азимут — это, например, азимут и угол места. То есть, они считают, что в 2:00 будет азимут. Таким образом, это вращение вдоль вашей прямой плоскости. А также высота, которая определяется относительно вашей передней плоскости. Эм, вы также можете определять азимут по сторонам света, верно? Так что вы можете, например, расположиться на 2° или 60° от севера и на 10° выше. Эм, это тоже совершенно верное направление. Существует множество причин, по которым подшипники могут быть такими сложными. Думаю, запись выступления будет опубликована в какой-то момент. Так что, если вам интересно, вы до этого доберетесь. Но всё это означает, что у меня болит голова, верно? Эти вещи невероятно сложны и ужасно раздражают. Поэтому я хотел создать библиотеку, которая избавит меня от необходимости что-либо испортить, или, по крайней мере, с низкой вероятностью того, что я что-либо испорчу. Эм, и в частности, меня беспокоит не столько то, чтобы сделать все правильно один раз, сколько то, чтобы делать это правильно снова и снова, верно? Например, кто-то другой написал код, и мне нужно его проверить, или я написал код в прошлом, и теперь мне нужно его изменить, или я пишу код и пытаюсь убедить кого-то другого в его правильности. Э-э, во всех этих вещах мне нужна помощь специалистов, а не необходимость самостоятельно выполнять такие операции, как умножение матриц случайным образом и квантовые преобразования, потому что это кажется слишком сложным и запутанным процессом. Эмм, я написал Squaba, чтобы использовать типы. Название "Squaba" происходит из кельтской мифологии. « Скваба Твин», что в переводе с кельтского означает « гребец волн», — это была самоуправляемая лодка, принадлежавшая кельтскому святому Манану Млейеру, которой управляли исключительно по велению лоцмана. Таким образом, предполагается, что вы сможете ориентироваться в нём, не зная таких вещей, как системы координат. Ты просто представлял, куда хочешь попасть, и оно туда и направлялось. Поэтому нам показалось уместным создать библиотеку пространственной математики, где не нужно будет ломать голову над всеми математическими выкладками и называть их одним и тем же словом. Эм, хорошо, вот как выглядит ссора. Вы создаете систему координат с помощью макроса, который называется system. Внутри есть структурное определение. Таким образом, вы можете написать pubstruct здесь, вы можете добавить, например, derive serialize внутри системного макроса. Вы просто определяете тип, но не определяете для него никаких полей. Это что-то вроде маркера. Вы также описываете, какой формат соглашения вы используете. Таким образом, я утверждаю, что обычный французский язык использует соглашение frd. Таким образом, оси XYZ направлены вперед, вправо и вниз. Аналогично, в системе координат самолета используются обозначения север, восток и вниз. А потом он генерирует для вас кучу всего остального. Таким образом, все преобразования координат и всё остальное вы получаете бесплатно. Обратите внимание, что причина, по которой вам нужно это сделать, заключается в том, что, как я уже упоминал, например, на Земле, если вы находитесь в двух разных точках Земли, у вас разные системы NED. Ваш север отличается от этого севера. Итак, нам нужно уметь работать с несколькими системами координат и говорить о них как о разных типах, чтобы знать, что эта координата находится в одной системе, а эта — в другой. Поэтому они не взаимозаменяемы, если только мы не будем переводить данные между ними. То же самое относится и к FRD. Если один самолет находится здесь, а другой — там, то у них разные системы координат. Эм, хорошо. Итак, у нас есть системы координат как тип, и затем мы можем строить координаты в заданной системе координат. Например, здесь мы хотим указать, где находится воздушный шар. Таким образом, мы создаём координаты с параметром типа plane FRD, поскольку это координаты относительно системы координат передней правой части плоскости. Мы хотим изготовить его из подшипника. А направление определяется комбинацией азимута и угла места. Итак, азимут составляет 60°, потому что мы сказали 2:00, а угол места — 30°, потому что мы сказали, что пилот увидел воздушный шар на высоте 30° над лобовым стеклом. И обратите внимание, что угол возвышения должен составлять от 90 до 90°. Не может быть так, что если у вас высота 110°, то вы на самом деле смотрите не в эту сторону, а вверх под углом 110°, а в эту сторону и вверх под углом 70°. И вот почему высота над уровнем моря должна составлять от 90 до 90 градусов. Поэтому и ожидается, что здесь... Поэтому строитель не позволит вам изготовить подшипник, не обладающий этим свойством. А затем в конце мы называем это строительством. Команда `um build` использует шаблон состояния типов, чтобы гарантировать, что вы установили как азимут, так и угол места, и ни один из них не имеет значения по умолчанию, равного нулю. А когда мы указываем координаты, мы также указываем направление и расстояние, то есть, как далеко это находится, и этого достаточно, чтобы получить координаты xyz. Таким образом, за кулисами это превращается в xyz. Нам также необходимо записать ориентацию плоскости. Итак, есть плоскость ориентации и используются углы Тейта-Брайена. Итак, это термины, обозначающие рыскание, тангаж и крен, которые

вы, возможно, уже слышали. Как видите, здесь я представил три ракурса. Это углы рыскания. Насколько сильно мы отклонились от севера? Северо-восток — это 45° к северу, а северо-восток — 22 с половиной градуса к северу. Вот в чём будет причина отклонения от прямолинейного направления. Потенциал тональности — это то, насколько вы повышаете высоту тона. Таким образом, это будет подъем на 10 градусов. И мы не будем снимать. Так что мы не стоим на боку. Эм, хорошо. Итак, это наша ориентация по n. А затем мы определяем GPS- координаты самолета. Это как показания какого-то прибора. Обратите внимание, что широта здесь также имеет параметр ` expect`. Это как распаковка с посланием. Потому что широта также не может превышать 90°. Таким образом, 90° широты — это, по сути, Северный полюс. Если у вас широта 110 градусов, это значит, что вы находитесь на той стороне Земли, на такой высоте. Таким образом, широта никогда не превысит 90 градусов. И это правило соблюдается в местной библиотеке. А в итоге получается что-то, что действительно выполняет проверку типов. Сейчас мы поговорим об опасностях. Эм, но вы можете построить преобразование отсюда EIF в N. Эм, используя метод, предоставляемый библиотекой, где вы указываете, что хотите преобразовать из EIF в N в заданном местоположении GPS. Итак, в этой точке на Земле, дайте мне способ преобразовать координаты Eiff ( мировые координаты XYZ) в локальную касательную плоскость (плоскость ND) в этой точке. А потом я говорю: хорошо, теперь мне нужно перевести показания компаса в этом месте в показания плоскости в этом месте. Итак, если мы возьмем самолет, э-э, самолет, как здесь, эм, ориентированный на север, а затем у меня есть мой самолет, как в п-н-э, черт возьми, это не работает. У меня есть летающий самолет, который летит с некоторым смещением относительно севера. Мне нужно указать библиотеке, как преобразовывать данные между этими направлениями, поскольку в обоих случаях присутствует вращение и перемещение. Таким образом, мы берем ориентацию в направлении N и отображаем ее, указывая, что эта ориентация находится в направлении N. Плоскость в направлении N имеет вид, равный нулю в FRD, потому что направление вперед в этом случае соответствует углу севера. Это довольно тонкий нюанс, но по сути мы говорим, что преобразование из этого значения в это означает, что при измерении отсюда это значение равно нулю. Если вам это было сложно понять, не беспокойтесь. Программирование, отвечающее за создание атмосферы, в данном разделе не будет рассматриваться. Но теперь у нас есть две трансформации. Мы можем связать их цепями. Таким образом, у нас есть преобразование, которое переходит из плоскости EF в плоскость NE, а затем в плоскость N. И у нас есть преобразование, которое переходит из плоскости N в плоскость FRD. И мы можем их комбинировать, потому что средний тип одинаковый. В итоге мы получаем преобразование из EF в плоскостную FRD. И вот этот тип проверок. Поэтому, если вы попытаетесь задать преобразованиям другой порядок или это преобразование будет для какой-либо другой системы координат, то здесь код не скомпилируется. Это одна из особенностей, заключающихся в том, что их необходимо правильно соединить. Итак, после получения этого подтверждения вы можете использовать преобразование, или в данном случае обратное преобразование, поскольку здесь преобразование выполняется из плоскости EF в плоскость FRD, а мы хотим перейти из плоскости FRD в плоскость EF. Мы хотим пойти в другом направлении. Таким образом, мы используем обратное преобразование, чтобы получить данные наблюдений за воздушным шаром в плоскости FRD и перейти к положению воздушного шара в плоскости EF, а затем в плоскости EIF мы можем преобразовать их в координаты WGS84, которые являются координатами GPS, и теперь мы можем вывести местоположение воздушного шара в координатах GPS. Хорошо. Вот и вся цепочка от начала до конца. Эм, насчет опасности я, пожалуй, отмахнусь от этого. В файле readme и документации Squaba объясняется, почему я считаю это правильным решением. Но это не небезопасность в смысле безопасности памяти. Это небезопасно с точки зрения типовой безопасности. Давайте пока оставим это в покое. В библиотеке Squaba нет никакого небезопасного кода в истинном смысле этого слова Эм, круто. Теперь у нас есть вся эта комплексная система. Самое интересное, и именно поэтому я выбрал Squaba, заключается в том, что все, что я вам объяснил до сих пор, на самом деле довольно просто реализовать. Сложность заключается в том, чтобы правильно определить порядок и убедиться, что типы корректно отражают то, что представляют собой координаты объекта, что на самом деле представляет собой преобразование и тому подобное. На этом всё. Библиотека существует и функционирует. Представленный здесь код, отражающий желаемую атмосферу, представляет собой несколько улучшений библиотеки, от относительно простых до гораздо более сложных. Итак, мы сейчас это рассмотрим. А теоретически, я думаю, что программирование, создающее нужную атмосферу, поможет нам справиться с двумя из четырех поставленных передо мной задач. Это моя текущая догадка. Эм, ещё один интересный момент, и ещё одна причина, по которой я выбрал Squaba, заключается в том, что всё это, касающееся систем координат, квантовых точек и вращений, — всё это объясняется в интернете. Это такая область, даже если она для вас, дорогой зритель, новая, на самом деле она очень хорошо

известна. Это не новость. Это несовременно. Это не новая разработка. Дело даже не в ржавчине. Это очень хорошо известные математические свойства и преобразования. Таким образом, я предполагаю, что соответствующие базовые знания достаточно хорошо разработаны. Итак, теперь мы попробуем использовать программирование для создания атмосферы. И с этого мы начнём, у меня есть небольшой список дел. Первым делом мы создадим макроконструктор азимута и системы координат WGS84 со статическими проверками высоты и широты. В частности, вы заметите, что при построении азимута я использовал построитель и задал азимут и угол места, но я задал их как константы, как будто это построитель, работающий во время выполнения программы. Так зачем же мне здесь нужен параметр expect? Было бы гораздо лучше, если бы у меня был макрос, который позволял бы задавать пеленг, используя азимут и угол места в качестве констант, и где макрос статически проверял бы во время компиляции, что мой угол места допустим, а затем просто следил бы за тем, чтобы он не был неправильно сформирован. Поэтому я хочу добавить этот макрос в код Vibe. А затем мы хотим сделать то же самое для WJS84, у которого есть широта, долгота и высота. Если широта хорошо известна, например, известна на этапе компиляции, то можно использовать макрос, позволяющий её построить. Итак, это первое, с чем мы попытаемся разобраться. Я уже довольно долго говорил. Давайте сделаем паузу и посмотрим, имеет ли это смысл? И о том, что представляет собой Squaba, даже если в процессе есть много неясных деталей относительно того, как она достигает своих целей, и о том, зачем вообще нужен ящик для неё, для чего он нужен и что мы собираемся сделать в первую очередь. Кажется, это должно быть доступно для просмотра на видео, не так ли? На первый взгляд, это не должно быть слишком сложно, но мы скоро это выясним. Вполне понятно. Прохладный. Все в порядке. Эм, использовать конструктор констант невозможно. Хм, это интересный вопрос. Было бы лучше использовать конструктор констант? Я так не думаю, потому что... утверждения на этапе компиляции возникают при добавлении паники в код. Как и вы, вы действительно паникуете. Проблема в том, что ошибка возникает на этапе компиляции, и поэтому компилятор знает, что нужно завершить процесс с ошибкой на этапе компиляции, а не во время выполнения. Если бы мы просто сделали широту здесь постоянной величиной. Это может быть постоянное событие. На самом деле, большинство методов конструктора здесь можно было бы сделать константными событиями. Проблема в том, что для возникновения ошибки компиляции всё равно потребуется внутренняя паника. Эм, но если вы используете построитель со значением, заданным во время выполнения, то вы не можете использовать что-то подобное, тогда, если вы просто передаете ему значение, заданное во время выполнения, вы не вызываете его в контексте константы. Поэтому паника там всё равно бы возникла. Таким образом, ожидаемое исчезнет даже при построении во время выполнения. и построение во время выполнения. Мне не нужна скрытая паника. Я хочу, чтобы это было явно выраженным ожиданием. Да, застройщик здесь может быть строительным, но это не даст мне желаемый объект недвижимости. Итак, давайте начнём наслаждаться атмосферой. Эм, я поступил так: из-за своей паранойи я создал на своем компьютере отдельную учетную запись. На самом деле, это должна быть отдельная виртуальная машина, но пока это не так. Эм, значит, отдельный пользователь, у которого оформлена покупка в Squaba, вот здесь. Эмм, и мы просто запустим Клода и посмотрим, на что он способен. А вот здесь у меня чек на то же самое. Итак, вот что мы собираемся сделать. Эм, я уже запускал там Клода. Итак, вы увидите, что здесь чего-то нет, но есть, э-э, генетическая голубка Клод, доктор медицины. Итак, он уже сгенерировал MD-файл Claude, который получился просто после запуска Claude, потому что мне сказали, что нужно выполнить команду Claude. Эм, такой вариант уже существует, потому что на его настройку потребовалось некоторое время. Теперь посмотрим, что произойдет. Эм, в ящике находятся детали для изготовления подшипников и системы WGS84. Однако, если у меня есть однако, я бы хотел иметь возможность для пользователей

создавать их без необходимости указывать высоту и широту соответственно. Когда углы для них становятся известны на этапе компиляции. Эм, дайте мне план, может быть, мне нужно несколько планов, потому что было бы неплохо, если бы вы сказали, считает ли система, что макропуть является правильным или нет. Эм, предложите несколько вариантов, как этого добиться. Э-э, точка. Может быть, предложите мне несколько вариантов того, как этого добиться с точки зрения эргономики, чтобы это было одновременно безопасно и эргономично? Прохладный. Ах, да. Истинный. Не забудьте сказать « пожалуйста». Пожалуйста. Нажмите Shift+Tab дважды, чтобы перейти в режим планирования. Хорошо, я перешёл в режим планирования, потому что некоторые люди сказали, что это хорошая идея. Ой, пожалуйста, дайте мне «Хорошо». Предложите три варианта и их преимущества и недостатки для достижения этой цели. Все в порядке. И теперь оно делает и делает выводы. Мы уже перешли в режим планирования. Я переключился. Хорошо. Таким образом, анализируется текущее положение дел в системах WGS для понимания контекста. Это хорошо. Это кажется вполне разумным решением. И поэтому система ищет строительных подрядчиков. Если этот кодекс не будет совершенным, все дети в Африке умрут от голода. Да, это ужасно. Верно. Хорошо. Давайте посмотрим, что там уже написано. — Там было написано: «Что у нас тут наверху? » Оба метода определения высоты и широты в настоящее время возвращают опцию, поскольку они проверяют углы в пределах допустимых диапазонов. Это правда. Это вынуждает нас вызывать expect, даже когда они знают, что скомпилировали их. Углы допустимы. Да, это действительно тот самый запрос. Три варианта. Вариант первый: конструкторы cons с непроверяемыми вариантами. Ага, это, по сути, то же самое предложение, которое обсуждалось в чате, верно? У вас есть константа, которая принимает цель повышения высоты, и она вызовет внутреннюю панику из-за константных утверждений. Эта проверка на этапе компиляции предотвращает ошибки во время выполнения. Да. Звонки не требуются. Да. Нулевые накладные расходы во время выполнения. Ну, вроде того. Это работает только с выражениями, которые могут быть вычислены как константы. Это, по сути, не недостаток. Это нормально. Я специально спрашивал, когда значения становятся известны на этапе компиляции. Для этого требуются константные обобщенные типы или проверка на основе макросов. Типобезопасные угловые обертки создают типы-обертки, такие как допустимая высота и допустимая широта, которые могут быть созданы только с использованием допустимых значений. Затем добавьте в конструктор методы, которые принимают эти типы без возврата параметра. Я думаю, это не сработает, потому что, мне кажется, у вас здесь та же проблема с новым. Теперь мне нужно будет распаковать новый товар, верно? потому что он возвращает опцию. А вот этот другой вариант, который не возвращает опцию с константным утверждением, можно будет вызывать в контекстах, отличных от константного, чего я не хочу. Вариант третий: перегрузки методов-конструкторов с различными типами возвращаемых значений. Добавьте новый метод-конструктор с разными именами, который принимает необработанные значения градусов и вызывает панику при корректном вводе. А, понятно. Так что мне ни один из них не нравится. Эм, вы хотите продолжить? Нет, продолжайте планировать. Пользователь отклонил план Клода. Прости, Клод. Э-э, мне следовало сказать: «Нет, я не буду. Это звучит слишком, слишком уж антропоморфизирующе». Эм, извините, Клод. Э-э, но это не совсем то, что я имел в виду. Эм, я бы хотел, чтобы было невозможно использовать версии, вызывающие панику, если

значения не известны во время компиляции. То есть, пользователь не должен иметь возможности предоставлять... на самом деле, я думаю, чего я действительно хочу, так это чтобы этот новый конструктор не вызывал панику во время выполнения Это высокопарное изложение мыслей. А, еще лучше. Рассматривается что именно сейчас? На данном этапе это заняло больше времени, чем написание вручную. Я согласен. Но самое интересное здесь то, что, если оно хорошо справится с этим, теоретически, я мог бы поручить ему выполнить множество подобных задач и просто продолжать работу. По крайней мере, в этом и заключается обещание генетического ИИ, верно? А может быть, я смогу запустить несколько таких систем одновременно и управлять ими с помощью другого ИИ. Я пока не готова полностью от этого отказаться. Также помните, что это одна из самых простых конфигураций, поэтому чуть позже мы перейдем к чему-то более сложному. Эм, хорошо. Что же предлагается взамен? Я понимаю. Да, именно этого я и хочу. Используйте con generics. Эм, у этого свойства нет. Это по-прежнему можно вызвать. Ага, понятно. Азимут и угол места являются общими понятиями. Интересный. Я думаю, мне это не нужно, потому что это должны быть числа с плавающей запятой. Эм, вам нужно уметь сказать, например, 80,3 градуса. Э-э, макросы конституции. Естественный синтаксис с вызовами макросов. Компилируемая функция аннулирования данных предотвращает любые ошибки во время выполнения. Макросы могут быть менее понятными. Это правда. А некоторые идентификаторы испытывают трудности со сложными макросами. Ах, нас не интересует поддержка идентификации. Это нормально. Эм, значит, для этого потребуются азимут и угол места по системе пеленга. Здесь возникает интересный вопрос: должна ли система служить аргументом для макроуровня, или же макроуровень должен быть готов построить подшипник любого типа? Хорошо. И поскольку это утверждение встречается здесь, всё должно быть в порядке. Думаю, я с этим согласен. Вопрос в том, является ли такое использование уместным или нет. Интересный. Третий вариант: шаблон проектирования «const builder» с фантомной проверкой. Да, это обладает тем же свойством, что и um of con generics. Хорошо. Похоже, что в итоге выбор пал на макрос. Эм, меня это вполне устраивает. Эм, вы хотели бы продолжить? Нет. Продолжайте планировать. Я рекомендую второй вариант, поскольку он обеспечивает наилучший баланс между гибкостью и эргономикой, сохраняя при этом безопасность на этапе компиляции. Какой подход вы бы предпочли реализовать? Я предпочитаю второй подход с использованием макросов. Потому что мне нужны значения в формате f64. Однако одна проблема с этим макросом заключается в том, что неясно, как пользователь указывает, выражено ли значение в градусах, радианах или какой-либо другой угловой единице. Эм, как сделать предложение? Эм, пожалуйста, предложите вариант, в котором единица измерения четко указана пользователем. Ага, верно? Представьте, что кто-то по какой-то причине не знал, что азимут измеряется в градусах, и поэтому попытался использовать радианы. Тогда это всё равно будет просто F64.

Давайте посмотрим, что они предлагают сейчас. Вариант 2 А. Хорошо. Итак, один из вариантов — это поставить градусы после « Да». Таким образом, это требует, чтобы оба значения были либо в градусах, либо в радианах. Я считаю, что это нормально. Эм, используя некоторые константы. Всё в порядке. Нет ни опции "из радиан", ни опции " из градусов". Так что я не знаю, откуда они планируют это взять. Эм, спецификация вложенных модулей. Эм, нет. Мне кажется, я предпочитаю макросы, специфичные для каждого суффикса. Нет, давайте выберем вариант 2А. Мне нравится вариант 2А. Я выберу вариант 2Б. Нет, я думаю, мне нужно 2 А. Хм, продолжай планировать. Давайте выберем вариант 2а, используя единицу измерения в качестве суффикса. Эмм, но, пожалуйста, имейте в виду, что для этих типов нет непроверяемого конструктора. Итак, нам нужно будет пройтись по построителю внутри макроса. Ага. Так что здесь возникает интересный вопрос, верно? Была ли эта информация полезна на данный момент? Например, обратило ли это внимание на вещи, о которых я раньше не задумывался? Я думаю, что имею в виду общий подход, о котором я не думал, но он тоже не работает. Поэтому я не знаю, насколько это полезно. Думаю, в каком-то смысле осознание необходимости создания этого подразделения здесь — это правильное решение. Эмм, но это было моё осознание, а не его, но я понял это, увидев то, что оно предложило. Эм, хорошо. Какова текущая ситуация? Ага. Итак, всё идёт своим чередом. Давайте сделаем утверждение. Используйте точный конструктор. Ага. То же самое относится к широте долготе. Единственная неудобная деталь здесь заключается в том, что высота должна быть указана в метрах. Эм, давайте, пожалуй, это исправим. А ещё я хотел использовать expectant вместо unwrap. А, добавьте макроэлемент из ягод. Добавьте макрос DGS84. Нет, продолжайте планировать. Э-э почти верно. Э-э, давайте начнём, мы почти на месте. Давайте также используем слово «ожидать» с содержательным объяснением того, почему оно не может потерпеть неудачу, в качестве аргумента. А ещё добавьте поддержку километров, а также высоты. Да, это тоже хороший вопрос, не так ли? Или вы бы сами придумали столько всего в процессе их реализации? Думаю, в данном случае я бы, наверное, так и поступил, потому что у меня достаточно опыта работы в этой проблемной области. Эм, но я не знаю, может, это только моя особенность, да? Хорошо, давайте посмотрим. Поэтому это дополнительный фактор, которого следует ожидать. Ага. Отлично. Выглядит неплохо. Это тоже выглядит неплохо.

Интересно также, что в макросе используется полный путь к типам, что хорошо, ведь это удобно, когда нужно сделать это в макросе, так что это хороший выбор. Эм, немного грустно, что в итоге получается что-то вроде полного использования всех возможных способностей. Таким образом, градусы измеряются в метрах. У вас есть градусы в километрах. Радианы измеряются в метрах. Радианы указаны в километрах. Эм, может быть, давайте сделаем так: нет, может быть, мы посчитаем, что этого достаточно. Думаю, давайте так и сделаем. Хорошо. Да, давайте сделаем это. Поднимите руки, вот макрос для обработки событий. Я точно знаю? Итак, давайте посмотрим. Итак, теперь добавляются эти вещи. Эм, и я думаю, мы можем пойти сюда и подключиться к агенту-сквабе. Посмотрите, что у нас тут есть. Ой, почему же это больше не репозиторий Git? Что? Это интересно. Почему? Почему этот репозиторий перестал быть Git-репозиторием? Или, возможно, по какой-то причине это просто не мой репозиторий Git. Эм, хорошо. Таким образом, это будет добавлено в инструкции. Безопасный способ построения моделей медведей с использованием известных углов на этапе компиляции, ограниченное количество вызовов Spec при проверке высоты с использованием градусов и радиан. Эм, мне кажется, всё в порядке. Да, пожалуйста. Да, ну почему, почему было принято такое решение? Я не совсем понимаю, почему. Получить статус. Ах, сомнительное право собственности в этом репозитории. Прохладный. Давайте так и сделаем. Давайте начнём Ага, отлично. Ох, ладно. Так вот, оно творит здесь какие-то печальные вещи, добавляя пробелы. Я не понимаю, зачем там пробелы в конце. Поэтому нам придётся это всё исправить. А затем в Geodetic RS добавляется вот это... Да, это выглядит нормально. Всё в порядке. Этот макроснимок всё ещё немного меня огорчает, что он должен быть таким выразительным, но ладно. Мне действительно любопытно посмотреть, какие именно тесты будут добавлены. Эм, хорошо. Итак, в каком направлении мы движемся? Макроуказан подшипник. Да, я до сих пор не уверен, хочу ли я, чтобы там был FRD, или же пользователю придется писать: "let bearing one colon coordinate angle bracket FRD equals" и затем константу азимута, потому что у нас уже есть прецедент для этого. Итак, если вы посмотрите на координаты, то увидите макрос для построения правил макроса координат. Эм, и вы увидите, что здесь я использовал суффикс inrd, и, кажется, мне больше подходит именно он. Эм, давайте скажем так: на самом деле, я думаю, я хочу, чтобы этот макрос выглядел немного больше как координатная и векторная модель. Таким образом, можно использовать выбранную систему координат в качестве суффикса, как в FRD. А что вы думаете? Геодезический или геодезический. Я неправильно написал слово geodetic? Геодезический.

Я уже ничего не знаю. Геодезический. Геод. О, это геодезический метод. О, боже. Это серьёзная ошибка, которую нам нужно исправить. Абсолютно верно. Эм, хорошо. Давайте посмотрим. Я попросил изменить это, и мне ответили: "Переместите эти элементы". Теперь я забыл, делает ли это его необязательным. Да. Поэтому я хочу, чтобы это правило тоже было необязательным. Нет. Эм, это почти верно. Однако, как координаты, так и векторы позволяют вызывать макрос без указания целевой системы координат. Взгляните на первый вариант каждого из этих макросов. в at matcharmm для определения каждого из макросов matcharm. Это интересная структура, и мне нравится такой подход. Если бы я попросил кого-то внести это изменение, и он, например, не очень знаком с макросами Rust, я бы посоветовал ему посмотреть вот на этот макрос, как я это сделал в другом макросе. Посмотрите на это. Давайте посмотрим, что здесь написано. Таким образом, при отсутствии координат, поиск определения в этом месте переходит к версии, указанной в подчеркивании Ага. Поэтому это будет обновлено. Давайте посмотрим, что у нас получилось. Так что да, этот подшипник номер два не подойдёт, потому что его нельзя будет определить автоматически. Потому что необходимо указать тип. Так что это вряд ли сработает. Эм-э, я думаю, что вторая строка кода, отвечающая за подшипники, в тесте стыковки не сработает, потому что компилятор не сможет определить тип для нужной системы координат. Думаю, для этой строки вам нужно будет добавить спецификатор типа uh ко второму подшипнику, например, координату FRD. Ага. В каком-то смысле удивительно, что он сам не запускает проверку документации, верно? Я имею в виду, я могу дать ему команду это сделать. О, оно думает. Пользователь абсолютно прав. Мне нравится, что это похоже на внутренний монолог. О, боже, он прав. Это правда. Итак, следующий фрагмент довольно хорош. Отличное наблюдение, не правда ли? Итак, в примере с врачом, если мы хотим показать использование макроса без указания системы координат, нам нужно либо добавить аннотацию типа, как я уже говорил, либо использовать направление в контексте, где тип может быть определен автоматически, либо просто удалить этот пример. И действительно, там написано, что я прав. А потом, мне вдруг стало ясно, что это действительно смешно. Ага, круто. Теперь мы будем использовать это для конкретного варианта, затем этот и тот. Да, выглядит неплохо. Здесь кто-то в чате сделал очень интересное наблюдение, не так ли? Например, если мне нужно дать такую подсказку, разве я не предпочёл бы научить этому человека, чтобы он мог лучше это делать, вместо того, чтобы учить этому ИИ, а потом никто от этого не получит пользы? Возможно, Google собирается обновить это определение. Это нормально. Да, давайте начнём.

Хотя это и интересно, поскольку не сулит ничего хорошего для других изменений, но посмотрим. Эм, круто. Теперь то же самое будет сделано и для WS84. Эм, хорошо. Итак, какие же тесты добавляет эта функция для проверки макроскопического состояния подшипника? Мне всё ещё интересно, что я здесь думал о системе координат WGS84. Эм, да. Хорошо. Так что это хорошее наблюдение, не так ли? Итак, при определении азимута необходимо указать целевую систему координат. В случае с WGS84 это не требуется, поскольку тип цели — просто WGS84. Универсального решения не существует. И, как указано, поскольку для системы координат WGS84 не требуется указание системы координат. Это уже конкретная система координат. Я думаю, что точка с запятой в шаблоне не нужна. Эм... должно быть вот так. Но позвольте мне перепроверить, если были другие, то они следовали другой схеме. Отлично, здорово. Что именно проверяется? Градусы в явной системе координат с использованием выведенной системы координат. Чеки здесь. Это не сработает, потому что, как вы уже догадались, используется функция d, которая является вспомогательной функцией и используется в других тестах. Итак, если мы перейдем к направлению, и вы прокрутите вниз, то увидите, что во многих тестах я сравниваю, например, азимут с параметром d, а d — это всего лишь вспомогательная функция, которую я определил вверху, чтобы вы могли задать градусы как f64 и получить их обратно в виде хорошо типизированного угла, без необходимости писать весь угол заново в градусах. И, я думаю, он уловил эту закономерность из других тестов, и поэтому он использует это. Приятно видеть, что проверка метода равна 20, а угла места — 10. Выведенная система координат, радианы с явно заданными, радианы с выведенными граничными условиями, радианы на границах. Эм, да, это нормально. Однако отсутствует тест, который вызовет панику. Эм, или, по сути, паниковать вообще не стоит, верно? Должен быть тест, который имитирует ошибку на этапе компиляции, и я думаю, это будет действительно интересно. Посмотрим, поймет ли оно, что ему следует добавить этот тест самостоятельно. О, я собираюсь добавить тест для макроса W84. Вероятно, они будут очень похожи. Эм, широта, долгота. Не понимаю, почему написано «О, это нужно перевести в метры», ведь ввод был в километры. Хорошо, это допустимо. Эм, граничные значения для широты и долготы. Интересно, не возникнут ли проблемы с этими радианами из-за приблизительных чисел с плавающей запятой, но посмотрим. Эм, испытание грузоподъемности. Да, это нормально. Вы можете провести тест грузоподъемности, но это не сработает. Ой Макрос испытывает трудности с обработкой отрицательных чисел. Ах, я, собственно, этого и не скучал. В макросе используется тип токена TT, но необходимо использовать литеральный тип. Здесь не следует использовать выражения. На самом деле, выражение допустимо, если оно является конформистским. Нет, потому что если это " Да". Хорошо, это допустимо. Эм, значит, это должны быть выражения, чтобы они могли быть произвольными выражениями. Если это выражения времени выполнения, то проверка константы (const assert) здесь завершится ошибкой. Так что всё в порядке. Сначала напишите код для теста. Да, я мог бы сначала заставить его выполнить тест, а затем просто попросить его сделать это с помощью собственных тестов, вместо того, чтобы, знаете ли, постоянно мне об этом напоминать. Эм, создать конструктор систем. Это нормально. Ага. И теперь возникает проблема: если вы используете выражение, то вам не разрешается использовать произвольные символы, и следующее выражение не должно содержать только пробелы. За выражением могут следовать лишь определённые вещи. Э-э, у нас разный синтаксис, мы специализируемся

по-разному. О нет, мне это не нравится. Нет нет нет. Итак, здесь возникает интересный вопрос: хотим ли мы пока ограничиться только литералами, на которые это ограничение не распространяется, или же нас устроят выражения, а затем мы переключимся на радианы и используем выражение в скобках? Эм, я бы хотел избежать указания одной единицы измерения для всего макроса. Э-э, потому что однажды нам может понадобиться изменить это таким образом, чтобы разные аргументы можно было указывать в разных единицах измерения. Эм, давайте лучше переключимся на синтаксис « э-э» или «рад». И посмотрим, что из этого получится. Неопытный разработчик может принять первую итерацию, и это станет проблемой. Это правда, но ведь необходимость в пересмотре никуда не исчезает, верно? Эм, но правда в том, что мне кажется, предложенные варианты были не особенно удачными. Как и в прошлый раз, мне пришлось руководствоваться собственным суждением, верно? Ой, нет, теперь они решили добавить поддержку произвольных единиц измерения. А теперь еще и макросы стали невероятно популярны. Мне это не нужно. Нет, давайте не будем добавлять поддержку смешанных юнитов. Эм, это можно отложить на потом. Эм, поскольку в нынешнем виде это сделало бы макрос довольно некрасивым. Такое ощущение, что оно заменяет не мозг, а клавиатуру. Я тоже так считаю. И снова это первый пункт в моем списке. Итак, я уже упоминал, что у меня есть и другие дела. Следующий элемент — это инструмент для формирования углов рыскания, тангажа и крена. Так что помните, что в презентации я смогу к этому вернуться. Итак, для построения ориентации вы задаёте углы Брайанта, а именно рыскание, тангаж и крен. И здесь порядок имеет важное значение. Важно, чтобы сначала было рыскание, затем тангаж, а потом крен, потому что это внутренние вращения. Таким образом, тангаж применяется после поворота относительно рыскания, а не сначала применяется, а затем происходит поворот. Это не имеет значения для рыскания и тангажа, но имеет значение для крена. Представьте, что самолет кренится, а затем вы изменяете тангаж. Это отличается от ситуации, когда сначала начинаешь с высоты тона, потом... а потом перекатываешь. В итоге вы получаете два разных ракурса. Эм, и поэтому действительно важно, чтобы сначала был рыскание, затем тангаж, а затем крен. Именно поэтому я поместил это в синтаксис вызова функции, а не в качестве построителя, потому что в качестве построителя вы могли бы устанавливать их в произвольном порядке. А если бы вы могли установить тангаж раньше, чем рыскание, вы бы с удивлением обнаружили, что рыскание произошло первым. Обойти эту проблему с помощью построителя можно, используя шаблон проектирования «тип-состояние», который указывает, что параметр рыскания — единственный параметр, который можно установить, и его необходимо установить первым. Итак, вы создаете конструктор. Единственный способ управления на нём — это рыскание. После того, как вы установили угол рыскания, единственный способ его изменить — это установить угол тангажа. После того, как вы это настроите, единственное, что вы сможете установить, это размер рулона. И только после того, как вы это настроите, вы сможете вызвать функцию сборки. Э-э, это обеспечит соблюдение того же порядка. Хм, сможет ли оно это сделать, я не уверен. Я не знаю, легче это или сложнее. Пока что давайте не будем усложнять. Радианс излучает с выражением лица. Да, давайте начнём Оно еле-еле плетется. Мне нравятся все эти синонимы к слову «мышление».

Ой, здесь всё ещё слишком жарко. Но, по крайней мере, ситуация не так плоха, как на прошлой неделе. Эм, я внес такое же изменение и здесь. Всё в порядке. Теперь, что мне здесь нравится, так это то, что, ммм, было бы здорово вместо метров и километров использовать здесь, ммм, идентификатор, а затем создать отдельный макрос, который бы разворачивал коэффициент идентификатора между метрами и километрами. Но это не имеет значения. Э-э, что я говорил? О да, хорошо то, что когда я меняю свое мнение, как здесь, мы понимаем, что нельзя использовать подход с суффиксом, потому что тогда это должно быть буквальное значение, а не любое выражение. И, вероятно, было бы неплохо иметь возможность использовать выражения, например, чтобы можно было написать, я не знаю, э-э, 45 / два в качестве заданной степени. Эм, я мог просто указать ему сделать это по-другому, и тогда оно бы это сделало. Конечно, я мог бы изменить это вручную или использовать, например, групповую политику или что-то подобное для замены, но таким образом мне этого делать не нужно, что очень удобно. Эм, почему порядок действий в конструкторе имеет значение для расчетов? Для расчетов это не имеет значения. Расчеты всегда будут производиться по схеме: сначала рыскание, затем тангаж, затем крен. Но это имеет значение для восприятия пользователем. Таким образом, если пользователю разрешено задавать сначала тангаж, затем крен, затем тангаж, а затем рыскание, то есть задавать их в обратном порядке, он может ожидать, что они будут применяться именно в таком порядке, но это не так. Именно поэтому я хочу заставить их указывать параметры рыскания, тангажа и крена, чтобы у них не возникло путаницы в порядке их применения. Да, это нормально. Вы пробовали джиу-джитсу? Нет, я еще не делал этого. Это где-то есть в моем списке. Хорошо, тест успешно пройден. Выполните список дел. Проведите более масштабное тестирование, чтобы убедиться, что мы ничего не сломали. Хорошо, это допустимо. Сейчас выполняется множество тестов. Мне это не совсем нужно для запуска всех тестов, но вполне достаточно. Вот и всё. Хорошо. Эм, да. Однако отрицательных результатов тестов здесь нет. Это тесты, которые не скомпилируются. В сообщении говорится, что это не должно скомпилироваться, потому что предоставленные во время компиляции значения выходят за пределы допустимого диапазона. Э-э, что нужно сделать, чтобы добавить их. Думаю, самый простой способ — добавить тесты документации, вероятно, непосредственно в макрос, используя атрибут compile fail. Убедитесь, что ошибка компиляции возникает по правильной причине. Именно такие подсказки я даю инженерам, с которыми работаю: «Есть такая штука, как тест Dock "Complete-Complete-Fail", который можно использовать, чтобы проверить, что что-то не компилируется. Просто запустите его хотя бы раз, чтобы убедиться, что результат ошибки соответствует ожидаемому» Компиляция завершилась неудачей. Угол возвышения сквоши более 90°. Угол возвышения менее 90°, более половины радиана и менее половины отрицательного пи радиана. Эм, да, я думаю, что это должны быть разные тесты документации, потому что нужно проверять, что каждый из них не компилируется. Просто раздражает, что приходится повторять определение. Итак, на самом деле я собираюсь сказать, что давайте также воспользуемся префиксом в этих тестах документации, проверяющих ошибки компиляции. Чтобы избежать повторного использования и

вызовов системы для каждого из них, поскольку это не сильно улучшает пользовательский опыт. И, как мне кажется, здесь есть одно интересное наблюдение: именно это я имею в виду, когда говорю, что значительная часть моей работы на самом деле не является применением шаблонов. Эм, я имею в виду, что в этом плане все довольно неплохо, понимаете, это не значит, что это бесполезно. В итоге получаются вещи, которые в основном верны. Оно способно приблизительно выполнять команды, но это не значит, что оно работает самостоятельно. Мне кажется, мне постоянно приходится направлять этот процесс, но я думаю, это потому, что он должен создавать вещи, которых на самом деле нигде больше не существует, и поэтому он требует постоянных подсказок. И это, я имею в виду, это всего лишь подозрение с моей стороны, но я подозреваю, что если бы я попросил его создать интерфейс командной строки, который загружает файл из хранилища S3 по заданному ключу, он бы легко создавался за один проход, верно? И именно потому, что я этого не делаю, мне приходится постоянно помогать ему, чтобы он знал, какие более мелкие шаблоны применять и комбинировать. Эм, круто. Прохладный. Теперь эти линии скрыты, чего я и добивался. Ага, круто. Да, давайте так и сделаем. А затем — для определения широты. Да, выглядит неплохо. Это действительно ошибка компиляции? Теперь у меня ошибка компиляции документа rest. Ага. Отлично. Эм, идеально. Все тесты документации, вызывающие ошибку компиляции, проходят успешно, что означает, что ошибка компиляции возникает по правильной причине. Ах, вы не проверили, что причина правильная. Можно проверить, насколько информативны сообщения об ошибках, протестировав вручную один из случаев сбоя, чтобы увидеть, какое сообщение об ошибке появляется. Да, хорошо, э-э, я не думаю, что это сработает. Почему программа пытается создать это в slashtemp? Запустить это будет невозможно, вы не сможете запустить файл с кодом Rust во временной папке, потому что вам понадобятся зависимости и тому подобное, а значит, потребуется целый проект Cargo. Вместо этого попробуйте просто добавить пример, который мы сможем позже удалить. Эм, круто. Да, дерзайте. Да, было бы здорово иметь возможность указывать процессу компиляции, как именно он должен завершаться с ошибкой. На самом деле, если вам нужны действительно сложные ошибки компиляции, то вам следует использовать что-то вроде... ой, я забыл название этого крейта. Эм, в Rust ошибка компиляции assert. Есть... как это называется? Это не статичные утверждения. Это называется " ах, форкирует компилятор". Нет. О, попробуй построить. Вот он. Попробуйте собрать. Этот парень позволяет писать тесты, в которых вы проверяете, что компилятор

выдает о фрагменте кода. Эм, но мне кажется, это несколько излишне прямолинейное замечание. Сообщение об ошибке компиляции теста. Ага, и вы можете заниматься грузоперевозками, это нормально. Хорошо. Ага. Итак, если вы посмотрите на этот пример, то увидите, что паническая высота должна составлять от -90 до 90 градусов, что в точности соответствует нашим требованиям. Идеальный. Сообщение точно соответствует тому, что нам нужно, и называется ошибкой компиляции E0080. А теперь он попробует сделать то же самое для W84. Это нормально. И теперь этот файл удаляется. Это нормально. А теперь давайте посмотрим. Да, таким способом запустить doc test невозможно. Это тоже не сработает. Вот и всё. Хорошая работа. Прохладный. Итак, я думаю, на этом всё и закончилось. Что у нас тут? Краткое содержание. Хорошо, они добавлены. Они были подтверждены. Содержит понятные сообщения об ошибках. Улучшены тесты стыковки. Идеальный. Спасибо. Эм, не могли бы вы, пожалуйста, сделать коммит с сообщением, которое объяснит, почему я не могу набрать текст, объяснит компромиссы, на которые мы здесь пошли, как синтаксиса RAD Expert, так и для других вариантов? Возможно, дело именно в этом, что объясняет любые неочевидные моменты. Давайте попробуем. Эм, компромиссы, на которые мы пошли при проектировании или реализации, например, использование de expert вместо expert degg. А чтобы еще больше усложнить задачу, постарайтесь обернуть все преимущества, а не код, в сообщение коммита, чтобы оно соответствовало соглашениям Git о коммитах. Да, я планировал провести уборку перед следующим мероприятием. Оно сигналит. «Гудение» не является синонимом «для размышления». Да, это можно добавить. Это нормально. О, а что там было написано? Здесь, наверху, было написано что-то, что выглядело как завершение его рассуждений. Давайте посмотрим, как это выглядит. Эм, хорошо. Хорошо, это первый пример, первая строка уже слишком длинная. Нет, первая строка этого сообщения коммита слишком длинная и не соответствует соглашениям Git о создании коммитов. Давайте попробуем сделать так, чтобы заголовок соответствовал семантическим правилам коммитов. Хорошо, посмотрим, станет ли лучше. Хорошо, ещё одна нога. Это хорошо. Макросы безопасного азимута и системы координат WGS8, созданные во время компиляции. Хорошо, хорошо. Так выглядит лучше. Вводит макросы для построения подшипника в значениях WS. Устранение сбоев во время выполнения для известных допустимых углов. Теперь пользователи могут писать код непосредственно в системе, вместо того чтобы требовать вызовов expect. Нет. Эм, когда вы упоминаете типы или очень короткие фрагменты кода, пожалуйста, размещайте их в заключительном тексте. Кроме того, если у

вас есть целая строка кода или несколько строк кода, пожалуйста, размещайте их в блоках кода с отступами. Поэтому мне нужно рассказать обо всех своих предпочтениях. Но ведь подобные вещи я бы разместил в облачном хранилище MD, верно? То, что я хочу, чтобы мои сообщения в коммитах выглядели именно так, — это не то, что я хочу повторять каждый раз. Эм, хорошо. Э-э, просто напишу, да, теперь мы говорим по делу, вместо того чтобы требовать вызовов expect. Эм, а какие, по его мнению, существуют компромиссы? Драд работает с этим макроизмом. Ага. Да, константные утверждения. Это нормально. Прохладный. Э-э, единственное, что я хотел сделать, это пробежаться... да, это нормально. На самом деле, у меня такое чувство, что мы сейчас подумаем: «О, это нормально». Ага, конечно. На каком этапе я хочу, чтобы оно остановилось? Я думаю, я сделаю вот так. — Хорошо, я просто исправлю это вручную. Эм, почему моя история просмотров повреждена? Это очень неприятно. Эм, я хочу, чтобы это был Джон с сайта thequareplanet. com, и Джен из AI. Какой параметр конфигурации позволяет установить это глобально? Глобальный. Прохладный. Эм, э-э, я уже всё настроил. Так что, если попробуете ещё раз, всё должно быть хорошо. Перед подтверждением убедитесь, что вы запустили форматирование груза. Ах, да. Контекст оставлен до тех пор, пока Autoco Compact не достигнет 19%. Да, я слышал о... э-э, об этом... компактном автомобиле и о том, что его действительно следует избегать. Поэтому, пожалуй, вполне уместно, что мы подошли к концу. Эм, ещё кое-что я сделаю, пока мы тут этим занимаемся: я вернусь и возьму свои инструкции для... Ой, мне нельзя редактировать этот файл. Хм? Э-э, псевдо-судебный иск, а на самом деле псевдо-административный захват. Почему нет? Давайте упростим задачу. Эм, давайте спустимся сюда и скажем, перейдём к соглашениям о фиксации изменений. При написании сообщений к коммитам, пожалуйста, обязательно объясните любые неочевидные компромиссы, на которые мы пошли при проектировании или реализации. Оберните все преимущества, но не код, в формат mat, чтобы получить доступ к соглашениям о коммитах. А что ещё я написал? Это касается, в частности, заголовка. Кроме того, следует придерживаться семантических соглашений при составлении заголовка коммита. Прохладный. Думаю, это всё, что я

дал этому толчок. Теперь у нас есть это на будущее. А теперь давайте посмотрим, работал ли он в грузовом формате. Подтверждает изменения. В этом отношении никаких изменений. Теперь всё хорошо. Продолжить. Получить коммит. Меня устраивает вариант "в соавторстве". Это хороший вопрос. Эмм, у меня... я не думаю, что там указана стоимость, потому что у меня тарифный план "Профессионал". Эм, это хороший вопрос. Посмотрим, попаду ли я к Клоду. Я сделаю это со своего телефона, чтобы мне не приходилось входить во все системы, отображаемые на экране. Посмотрим, покажет ли это мне стоимость. авторизоваться. Войти. Посмотрим, что там написано. О, снижение стоимости, снижение стоимости. Ага. Хорошо, я так и предполагал. Но есть ли способ узнать стоимость, даже если у меня есть подписка? Вот что я хочу узнать. Да, именно так. Все в порядке. Что ж, мне кажется, теперь у нас есть эта функция. Итак, окончательный взгляд на получение статуса. Эм, это нормально. В логе мы видим большое сообщение о коммите, но обратите внимание, что восклицательные знаки неправильно экранированы. Итак, давайте внесем поправки. Эмм, символы в сообщении команды `get commit`, которое вы только что написали, неправильно экранированы. Пожалуйста, исправьте это, внеся изменения в коммит. А оно на это способно? И давайте, э-э, добавим это к сгустку крови. Эм, убедитесь, что все восклицательные знаки в сообщении Git правильно экранированы. Э-э, оно всё ещё ускользает от восклицательных знаков. Давайте попробуем заключить всё сообщение в одинарные кавычки. Подождите, это просто... Нет, это точно оно. Допустить ошибку. Интересно, это всё ещё что-то вроде... Хм. Хорошо. Итак, теперь программа попытается поместить это во временную зону. Это нормально. Так выглядит лучше. Прохладный. Это была попытка представить это как убедительный аргумент в пользу того, что файл находится не там. Рассматриваемый здесь вопрос, состоящий из двух пунктов, — это просто неверный путь. Но я разрешу это удалить. Система считает, что это относительный путь сюда, но на самом деле это абсолютный путь. Прохладный. Хорошо. Итак, теперь у нас это есть. Итак, теперь я собираюсь загрузить Agentic, чтобы этот коммит оказался в другом репосте, к которому пользователь Agentic не сможет получить доступ. Эм, хорошо. Итак, давайте теперь вернёмся сюда. Э-э, и я думаю, теперь

давайте почистим, не так ли? О нет, очистите. Именно это я и имел в виду Прекратите это. Прозрачный. Прохладный. Мы вернулись. Хорошо. Итак, теперь у нас есть этот коммит. Мы сделали первую часть. Э-э, и на каком этапе мы сейчас находимся? А когда это началось? Хорошо. Технически, я думаю, мы начали примерно через полчаса. То есть, мы начали в шесть. Итак, у нас есть полтора часа, чтобы добавить эту функцию. Мне кажется, что это заняло больше времени, чем если бы я сделал это сам, но, думаю, получилось неплохо. Думаю, всё прошло неплохо. Все в порядке. Итак, давайте теперь попробуем функцию номер два. Итак, вторая функция — это, э-э, конструктор углов поворота, наклона и крена. Эмм, вот что я попытаюсь ему объяснить. В данный момент конструктор... нужно ли мне указать ему снова прочитать облачный MD-файл? Думаю, я всё-таки запущу программу и запущу её заново на всякий случай, вдруг она прочитает всё с нуля. Эм, хорошо. Значит, это правда. Я имею в виду, что значительную часть времени я тоже говорю, и, справедливости ради, Клоду нужно это учитывать. Эмм... при построении ориентации или вращения с использованием углов Тейта-Брайена. В настоящее время конструктор принимает три аргумента F64. Поскольку углы Тейта-Брайена являются внутренними вращениями. Поскольку вращения мозга Тейта являются внутренними процессами, давайте на самом деле запишем это немного по- другому. Этот конструктор не использует шаблон проектирования "строитель", в отличие от большинства других конструкторов в этом фреймворке. Это происходит потому, что вращения Тейта-Брайена являются внутренними процессами. Итак, я хочу, чтобы конструктор сообщал пользователю, что он не может выбрать другой порядок аргументов. Однако, мы рискуем тем, что пользователи случайно укажут неверные или укажут углы в неправильном порядке, что приведет к возникновению ошибок. Эм, пожалуй, давайте переключимся в режим планирования. Итак, я хотел бы добавить конструктор-строитель, который по- прежнему будет обеспечивать установку угла рыскания первым, затем угла тангажа, а затем угла крена. Но также убедитесь, что все эти аргументы и значения передаются через именованные функции или поля. Как вы думаете, как нам следует это сделать? На то, чтобы объяснить глупцу, чего ты хочешь, уходит больше времени, чем на то, чтобы написать что-то своё. Возможно, это будет интересно, если использовать функцию преобразования голоса в текст, это, вероятно, ускорит процесс. Посмотрим. Мне ведь очень помогает то, что я хорошо разбираюсь в этой теме, правда? В противном случае, это легко может привести к проблемам. Эм, хорошо. Давайте посмотрим, что у нас получилось. Пользователь описывает конкретную проблему с конструкторами в крейте Rust. В настоящее время конструкторы углов связывания Тейта принимают три аргумента. Эм, но мне нужен шаблон проектирования "конструктор", который по-прежнему обеспечивает соблюдение порядка и предотвращает путаницу в порядке аргументов. Поддерживает семантику, согласно которой вращения являются неотъемлемой частью процесса. Для начала вам нужно

посмотреть код. Да, я понимаю текущую реализацию. Начните с изучения исходного кода. Собираюсь просмотреть все файлы. Инженерное дело. Ах, просматривать весь файл запрещено. Полагаю, оно не хочет слишком сильно загрязнять свой контекст. Таким образом, программа пытается найти только те файлы, которые имеют отношение к делу. Ага. Хорошо. Что ещё у нас здесь есть? Таким образом, был найден конструктор, который действительно выглядит именно так. Затем программа ищет других строителей, в том числе тех, которых она использовала ранее, но, конечно, она об этом не знает. Эм, хорошо. И оно осознаёт, что ему необходимо использовать поэтапную схему построения. Хорошо Ориентация, определяемая углами Тейта-Брайена, и вращение, определяемое углами метки, напрямую зависят от трех угловых аргументов F64. Да, всё в порядке. Эм, используется паттерн построения состояния типа. Ага. Итак, это текущая ситуация, которая сложилась у застройщиков, и мы можем даже посмотреть. Итак, если вы посмотрите на что-то вроде направления, то увидите, что в настройках конструктора есть аргумент для системы координат, для которой мы строим азимут. А еще есть азимут и угол места, причем каждый из этих параметров является общим и может быть либо задан как имеющий азимут, либо как не имеющий угол места, либо как не имеющий угол места. В итоге получается тип данных, который читается как "у пеленга ne отсутствует азимут и угол места". А затем методы устроены таким образом, что если вы однажды задали азимут, то флаг "has azimuth" устанавливается, а параметр типа возвышения остается неизменным. А это значит, что вы можете расположить их в любом порядке, и это не совсем то, что нам нужно для ротаций в данном случае. Да, будет интересно посмотреть, успеем ли мы дойти до этого момента, прежде чем достигнем лимита использования профессионального тарифного плана. Думаю, нам следует это сделать. Эм, да. Каждый набор позволяет перемещать конструкцию из одного набора в другой. Функция сборки может быть вызвана только тогда, когда все параметры будут установлены. Большой. Эм, это главное, что мы пытаемся обеспечить. Я могу разработать аналогичный шаблон построения состояния типов, который будет обеспечивать использование фантомных типов. Укажите понятные названия методов, например, рыскание, тангаж и крен. Сборка разрешается только при условии, что все три параметра заданы в правильном порядке. Работает как для ориентации, так и для вращения. Почему они расположены в таком странном порядке? Хорошо, это допустимо. Э-э, технология «создать-разрушить» отслеживает угловые состояния. Ага. Поэтому я не думаю, что их нужно отслеживать отдельно, поскольку распоряжение уже исполнено. Думаю, можно просто отследить, какой из них был установлен последним. Эм, поэтому здесь нужен всего один аргумент. Я думаю, вам не нужно три. Эм, я думаю, вам это тоже может понадобиться, потому что при вызове функции build, я полагаю, вы будете build rotation или build. Да. Возможно, строителю такой тип не нужен. Э-э, фантомные типы. Я прекрасно понимаю, с чем вы столкнулись. Отлично. Эм, да. Мы используем шаблоны проектирования Builder во многих местах. Сначала нужно задать рыскание, затем тангаж, а потом крен. Избегайте использования методов защиты от воздействия прямых солнечных лучей с помощью изоленты. Используйте тот же самый конструктор состояний с жестким ограничением, что и для других конструкторов. Таким образом, требуется API, который выглядит следующим образом. Тейт Брайан строитель рыскание тангаж крен строительство. Тейт Брайан, строитель, рыскание, тангаж, крен, строительство. план реализации. Согласны ли мы с этим планом реализации? Я не думаю, что здесь нужны все эти маркеры. Посмотрим, сможет ли оно придумать, как этого избежать. Нет, продолжайте планировать. Думаю, здесь можно обойтись без трех параметров, поскольку вы знаете, что

параметры будут устанавливаться по одному и в определенном порядке. Давайте сформулируем это в виде вопроса. Посмотрите, что из этого получится. У нас отличное взаимопонимание. Помните, что вы можете стимулировать дальнейшее мышление, добавив слово «думать». Ультратонкий. Мне нравится ультратонкий материал. Это звучит очень серьезно. Хорошо, давайте посмотрим, что получилось Вы совершенно правы. Поскольку нам известен точный порядок следования элементов, мы можем использовать гораздо более простой подход, используя всего один параметр типа, представляющий текущее состояние. Рассматривая существующие схемы конусов, я вижу, что подобный подход используется в конструкторе пеленгов, где последовательно происходят переходы между состояниями, например, отсутствие азимута и наличие азимута. Эм, я думаю, что это отчасти так. В конце концов, пеленг включает в себя и азимут, и угол места, так что это не очень удачный пример, но давайте посмотрим. Да, мы можем использовать один параметр типа, представляющий текущий шаг в процессе. Это действительно хороший пример того, как, я думаю, в некотором смысле спасение для этих систем заключается в том, что, хотя они никогда раньше не сталкивались с тем, чего я пытаюсь достичь в целом, поэтому они не могут решить задачу за один раз, они видели примеры шаблонов состояний типов, примеры конструкторов и примеры состояний типов, где нужно установить еще одно поле. Поэтому, если я могу указать им, какие шаблоны нужно комбинировать, они могут построить желаемый конечный результат. Но это означает, что мне нужно будет довольно часто напоминать ему об этом, чтобы он сам понял, какие шаблоны нужно воспроизвести. Нужно зевнуть, нужно сделать бросок, нужно покатиться и завершить. Да, пожалуй, я с этим согласен. Это строительная компания. Оно имеет свой штат и проходит через эти штаты. Мне кажется, это вполне неплохо. Эм, ещё одна причина, по которой это не сработает, заключается в том, что, как мне кажется, в итоге у вас получится два типа конструктора: один для ориентации, а другой для вращения, которые будут идентичны, за исключением метода построения. И это кажется излишним. Эм, разве в итоге не получится два одинаковых типа конструктора, один для вращения, а другой для ориентации? А может, лучше ограничиться одним строителем? Возможно, стоит добавить второй параметр типа, указывающий, что именно мы сейчас создаём. Это довольно интересный вопрос. Будет ли быстрее, если я сделаю эту часть сам? Потому что, эмм, вот как это выглядит на практике. Думаю, пока всё примерно так, как я и ожидал, в рамках этого конкретного плана реализации. Но вот это: нам нужно добавить ещё один параметр, и этот параметр должен гарантировать, что если мы создаём ориентацию, то получаем конструктор, который мы называем «Build», и он создаст нам ориентацию. А это потребует написания кучи кода. Итак, давайте посмотрим, к чему это всё приведёт. Мне тоже интересно, как они мыслят. Блестящая мысль. Ух ты, нас назвали гениальными. Смотрите, как мы общаемся. Эм, функция D — это вспомогательный инструмент для проверки, что тоже интересно. Но здесь, в качестве пояснения, используется своего рода вспомогательный инструмент для тестирования. Эм, хотя в реальной реализации это использовать будет невозможно, я думаю, это нормально. Эм, я бы предпочла, чтобы Клод меня обругал. Да, я знаю, правда? Эм, можно ли сэкономить на жетонах, попросив сделать это более удобным, исключив такие вещи, как то, что вы правы? Да, но мне нравится, когда пишут, что у меня есть блестящая идея. Я согласен. Эм, это правда. То есть, в какой-то момент это действительно становится программированием, управляемым агентом, или это просто я указываю вам, что именно нужно делать? Но я думаю, что это тоже не совсем правильно, верно? Потому что я же не указываю ему, какие буквы и в каком порядке вводить. Мне кажется, что здесь подсказки всё ещё довольно высокого уровня. Это как если бы я составлял план реализации. Речь идёт не столько о самом плане, сколько о том, какой код должен существовать. Эм, это, возможно, сэкономит мне кое-что. Эм, хорошо. Таким образом, это два типа параметров: один — состояние, а другой — цель.

Это целевая точка ориентации и целевая точка вращения. Существует конструктор, который поддерживает состояние на целевом уровне. Orientation plane ND tate Brian builder возвращает вам целевую плоскость ориентации ND. И это возвращает вам целевую точку ротации из двух вариантов сборки. А затем вы используете разные варианты реализации сборки в зависимости от типа целевой платформы. Думаю, это так. Это также означает, что конструктор для вращения может быть небезопасным, в то время как конструктор для ориентации — безопасным. Это ценное наблюдение. Создание объекта вращения небезопасно, и нам бы хотелось, чтобы метод построения объекта вращения оставался небезопасным, но не тот, который используется для ориентации. Ага, это довольно интересный вывод. Жаль, что оно само до этого не додумалось. Эм, хорошо. Реализуйте целевую ориентацию с помощью конструктора Tate Brian, используя безопасную сборку, которая обеспечивает ориентацию, и небезопасную сборку, которая обеспечивает вращение из двух вариантов. В качестве отправной точки будет выбран застройщик Тейт Брайан. Ага, конечно, хотя, думаю, я бы хотел назвать это "Построй Тейта Брайана". Возможно, это был строитель Тейт Брайан. Возможно, это нормально. Эм, круто. Да, давайте начнём. Автоматическое принятие правок. Это задача высокого уровня, но тот, кто не умеет программировать, не сможет её выполнить, и, похоже, Vibe Coding это обещает. Так что, да и нет, верно? Если подумать, это может быть не то, что сможет сделать тот, кто не умеет программировать, но и не стал бы вообще браться за эту задачу. Это задача, очень ориентированная на программиста. Так что, я думаю, это нормально. Вопрос не в том, сможет ли это сделать человек, не умеющий программировать. Думаю, главный вопрос в том, сможет ли это сделать программист, который не очень хорошо разбирается во всех этих тонкостях. Эм, даже здесь, к сожалению, я думаю, ответ, скорее всего, будет отрицательным, верно? Или же это «нет» с оговорками, потому что мне пришлось рассказать о различных подшаблонах состояний типов, которые следует использовать, а это уже довольно глубокие знания в этой области. Хм, мне кажется, вы слишком многословны и назойливы, когда говорите о своих проблемах с общением. Наверное, я мог бы отдавать гораздо более короткие команды и быть не таким вежливым. Хм, это интересный вопрос. Думаю, мы попробуем это на следующем, верно? Эм, имело бы смысл, чтобы фантомные данные для состояния и цели были типа фантомных данных fn to t, поскольку эти типы ссылаются на то, что возвращается, или это не имеет значения? Эм, они не имеют в виду то, что возвращается, потому что обратите внимание, что конструктивный отдельный тип, называемый, например, «цель ориентации» и « цель вращения», не является фактическим целевым типом. Эм, но это хороший вопрос. Мы могли бы попросить его избежать введения дополнительного типа, используя FN, например, тип FN2, фантомные данные, вращение FN2. Да, это вполне возможно. Хорошо. Давайте поднимемся наверх и посмотрим, чего это уже достигло. Ого, это же целая куча кода. Все в порядке. Начинается с создания единой инфраструктуры для разработчиков. Есть модуль для создания проектов. Это вызовет путаницу. Итак, если вы посмотрите на нашу библиотеку RS, вы увидите, что там есть построитель, есть модуль построителя, но этот модуль построителя — это реэкспорт, позволяющий создать немного более удобную иерархию модулей. Поэтому я на самом деле не хочу, чтобы это добавляло что-то новое в реализацию. Я бы добавил, что здесь предполагалось добавить функцию реэкспорта, но фактическая реализация находится в другом месте. Позвольте мне создать новый построитель в файлах математического анализа RS, поскольку он будет создавать как вращение, так и ориентацию, а затем, возможно, предоставит к ним доступ через модуль построителя. Эм, хорошо, так вот, в математике, этот конструктор будет использоваться как математиками для вращения, так и инженерами для ориентации. Итак, вопрос в том, где это должно храниться, чтобы найти унифицированный конструктор для построения как вращения, так и ориентации из заданных углов

внутренних порядков, рыскания, тангажа и крена во время компиляции, одновременно предоставляя параметры имени, аргумент бренда или путаницу, использует тип st, чтобы гарантировать, что углы установлены в правильном порядке, и построить либо вращение с небезопасным параметром, либо ориентационно- безопасный. Я не думаю, что нам нужно что-либо выводить для структур маркеров здесь. Хотя, если вы не будете выводить для них данные, то и для этого это не получится. Поэтому вы не сможете получить отладочную информацию для этого, если не получите отладочную информацию для типов маркеров. Вам потребуется написать собственную реализацию отладки, что иногда и приходится делать. Да, я думаю, это нормально. Согласен, было бы неплохо избавиться от этих лишних типов целей. Вращение вокруг оси Z действительно является рысканием. Вращение вокруг оси Y происходит потому, что она находится в положении Y после применения первого вращения. А затем — вращение вокруг оси X с двойной тиком. после обеих предыдущих ротаций. Это и есть основная суть. Это нормально. Эм, хорошо. Ввод вручную позволяет избежать необходимости клонирования и копирования состояния и целевого объекта. Но для режима отладки это не сработало. И это также заставляло их клонировать и копировать, хотя в этом не было необходимости. Это интересно. Э-э, они подходят для любого типа целей. Это правда. с помощью методов рыскания, тангажа и крена, которые вы должны использовать для любого типа целей. Эм, изначально устанавливает ноль. Это нормально. Так говорит ракурс. Ага, это нормально. Итак, после установки угла рыскания следующим шагом будет установка угла тангажа. Этот метод доступен только при необходимости управления по рысканию и сохраняет управление по тангажу и крену. Когда требуется изменение угла наклона, единственное, что можно установить, это сам угол наклона, который, собственно, и задаётся, а затем возвращается значение «требуется изменение угла крена». Roll — это то же самое. Теперь всё завершено. И наконец, метод build доступен, когда целевым параметром является ориентация. Итак, если происходит рыскание, тангаж и крен. А вот ещё один. Ага. Это небезопасно, поскольку вы утверждаете, что связь между системами координат «от» и «до» позволит осуществлять типобезопасное преобразование между системами координат. Это утверждение должно быть верным. Ага. Хорошо. Таким образом, здесь в основном копируется комментарий по технике безопасности из существующего конструктора Tate Brian для вращения. Выглядит довольно неплохо. Эм, теперь мне нужно добавить точки входа для вращения и ориентации. Таким образом, утверждение о том, что " слишком много совпадений в строке для замены всех совпадений" изначально неверно. Хорошо, давайте посмотрим, что еще произошло Эм, ладно, были небольшие трудности. Существует два угла Тейта Брайана и два угла Улера. Это не должно изменить ни то, ни другое. Эм, хорошо. Итак, теперь добавили вот это. Пойдёмте. Давайте посмотрим, как это выглядит Постройте, чтобы построить это. Это отсылка к ракурсам Тейта Брайана Мне понравилось замечание о безопасности. Возвращает вам строитель, которому требуется поворот на рыскание с целевым вращением, и он просто создает новый экземпляр этого строителя. А что касается ориентации, да, я думаю, возможно, нам стоит добавить сообщение об устаревании и к старому конструктору, чтобы сообщить людям, что лучше использовать конструктор. Э-э

это добавит... Хорошо, значит, в модуль Builder в исходной библиотеке добавляется модификация, которую использует Брайан. Это тоже кажется вполне приемлемым. А теперь добавлены некоторые тесты. Как выглядят эти тесты? И ещё проверяется, что создаваемые для вращения квутернианы в основном одинаковы. Это кажется разумным. И то же самое происходит и с вращением. Это проверка, а это не проверка, вы можете вызвать функцию build только после roll. Ага. Это всего лишь тест с комментариями о случаях сбоев. Поэтому нам придётся ему это сообщить. Эмм, ладно, меня это не особо волнует, эмм, ладно. Теперь это похоже на поиск вспомогательной функции, которую она добавляет. Это нормально. А затем нужно исправить импорт. Теперь начнём тестовый запуск. А затем происходит обновление CloudMD. Прохладный. Нет, мне нужно сказать ему пару вещей. Давайте посмотрим. Мы следили за тем, что нам нужно было рассказать? Э-э, пару, э-э, давайте попробуем сделать это короче. эмм, чтобы проверить, будет ли оно по-прежнему работать правильно, если нет, если я не так хорошо умею с ним чётко выражать свои мысли. Э-э, избегайте добавления нового типа для ориентации целевого объекта. Просто используйте вращение и ориентацию напрямую. э-э, при этом фантомный тип — это э-э, фн т. Также, эмм, добавьте тесты для проверки того, что не должно работать, в тесты, вызывающие ошибку компиляции. Думаю, мне действительно стоит это написать Клоду, доктору медицины. Эм, что еще мы заметили, что могло бы измениться? Где-то есть ещё один. Эм, пропустите тесты по использованию разных единиц измерения угла, потому что они не сильно влияют на результат. М, и, кажется, это было всё. А, избегайте ненужного создания типов клонирования и копирования на основе маркеров. хм, клон вождения. Давайте попробуем избавиться и от режима отладки. Отладка и повторная отладка для типов маркеров не должны требоваться. Эмм, э-э, проверьте, чтобы грузовой док не выдавал никаких предупреждений о недействительных ссылках, э-э, я хочу проверить, чтобы у вас не было отсутствующих ссылок, э- э, о неправильных ссылках на документы. Итак, это довольно лаконичный вопрос, верно? Я прошу его внести пять разных изменений в предложенный им вариант. Это скорее чистое программирование с использованием ИИ, чем VIP-кодирование. Я думаю, это правильно. Но мне также кажется, что именно такой стиль, скорее всего, здесь подойдёт. Эмм, но я имею в виду, расскажите мне, чем именно это должно отличаться? Верно? Как вы думаете, есть ли другой способ сделать это, который сработал бы намного лучше? Ага, конечно. В фантомных данных реализованы функции копирования, клонирования и вывода. Поэтому внутреннему типу они не понадобятся. Ну, будем надеяться, что оно это понимает, верно? Что ж, посмотрим, сработает ли это.

Хорошо, давайте посмотрим, какие изменения это внесет. Таким образом, были удалены все производные типы и целевые типы, а затем исчезла и ошибка, но я все еще хочу, чтобы отладка выполнялась в построителе. Надеюсь, их вернут, потому что я всё ещё хочу, чтобы в конструкторе были функции отладки, клонирования, копирования и т. д. Конечно. А потом этот тип цели исчез. Это действительно здорово. Это было хорошее предложение в чате. А потом они изменили этот ошейник, чтобы избавиться от них. Просто позвольте себе наслаждаться атмосферой. Ах. Ага, круто. Это помогло избавиться от того, от чего я хотел избавиться. Добавить в основную документацию конструктора. Я занимаюсь созданием бренда магнитной ленты. Всё в порядке. А как это выглядит? Можно ли вызвать функцию build до установки всех углов? Могу ли я объявить о подаче? Подождите, можно ли задавать тангаж до рыскания? Но этот тест не пытается определить тангаж до рыскания. Первый тест стыковки не работает. Э-э, рыскание и крен. Хорошо, это действительно неправильно. Хорошо, тогда всё в порядке. И меня огорчило, что список задач не обновлялся по мере его выполнения. Я думал, что это входит в его обязанности. Эм, я думаю, что первый тест на ошибку компиляции на самом деле проверяет не то, что нужно, потому что он вообще не пытается установить то, что пытался установить — угол поворота. Это позволяет проверить, что каждый тест на сбой компиляции завершается с ошибкой по правильной причине. Также, э- э, убедитесь, что тип построителя по-прежнему равен, сам э-э, отладьте, клонируйте и скопируйте. А ещё, пожалуйста, показывайте мне список дел по мере их выполнения. Посмотрите, поймет ли оно, что это значит. Ага, список задач обновился. Теперь у меня есть список дел. Хороший. Хорошо, значит, дело в понимании этой части. И мы забыли добавить, или мы добавили к Клоду? Нет. Поэтому нам нужно добавить инструкции о том, как тестировать ошибки компиляции. От чего мы отказались? VIP-кодирование. Мы занимаемся программированием, создающим особую атмосферу, чувак. У нас отличное взаимопонимание. Эм, метода броска кубиков не существует. Хорошо. На экране слишком много кода для этого. Я не знаю. На экране не так уж много кода. Это просто Клод. Но я прокручиваю страницу вверх, чтобы посмотреть, что это за код. Это правда. Мне кажется, здесь возникает интересный вопрос.

Да, я думаю, это не сработает. Я не думаю, что это проверено на работоспособность, потому что, по-моему, это не так. Например, производная функция будет существовать, но она будет неверной, потому что для её использования потребуется клонирование и копирование состояния. Эм-э, можете добавить это в claw. md? Давайте начнём с самого начала. Проверьте каждый блок ошибок компиляции, используя пример файла, который мы сможем удалить позже. Не могли бы вы также добавить Клоду несколько инструкций о том, как правильно писать правильно компилировать тесты на ошибки? О, мы приближаемся к концу компактного окна. Кроме того, убедитесь, что производные функции для построителя действительно работают и проходят какие-либо тесты. Возникающая проблема — это тот тип проблем, которые проще всего решить самостоятельно. Это правда, но об этом говорят многие, и это, кажется, хорошо известная проблема в среде Rust, верно? Создаётся впечатление, что это должно просто исправиться. Если вы попытаетесь использовать только код, основанный на атмосферных принципах, это просто потерпит неудачу. Вероятно, это правда. Было бы забавно, если бы Клод нанял нескольких фрилансеров, которые смотрели бы трансляцию и прислушивались к вашим отзывам. Это правда. Может, мне просто связаться с Anthropic и сказать: «Привет, я попробовал использовать твою штуку. Посмотри, где она работала, а где нет. Эм, хорошо. Давай вернемся и посмотрим, что она сделала здесь». Эм, я не думаю, что это сработает. Чтобы протестировать эти примеры, используйте Cargo, а не Rusty напрямую. Но давайте сделаем эти примеры не бинарными файлами. Это в духе. Если это не в духе, я не знаю, что тебе сказать. Эм, да, это нормально. « Reticulating» звучит не как слово. Да, попытка запустить Rusty напрямую — это явно неправильно, верно? Ты можешь переместить все эти файлы. Эм, я буду педантичным. Да, это нормально. Я искал педантичные определения кодирования. Это обязательно подразумевает нежелание смотреть на сам код или пытаться его понять. Код. Это сплошные подсказки и результаты без учета важных вещей. И мне это совсем не нравится. Эм, да, я думаю, кто-то здесь, в комментариях, высказал хорошую мысль, что если бы я так сделал, это было бы не особенно интересно, верно? Мне кажется, в итоге получилось бы так: мы бы просто наблюдали, что это не работает, и пошли бы домой, что не кажется таким уж полезным. Эм, хорошо. Что он сделал? Он переместил все примеры и запустил их как примеры, а также просмотрел сообщения об ошибках. И я имею в виду, это один из тех случаев, когда я просто доверяю ему, что он правильно проверил вывод. Эти ошибки выглядят разумно, и кажется, что они соответствуют тому, что он ожидает, но я на самом деле не знаю, был ли код в каждом из этих примеров тем, который он проверял. Эм, но это нормально. Это на уровне вайбов. Эм, да, теперь вы можете снова удалить эти примеры.

Возможно, вы оцениваете языковую модель. Возможно, CL действительно может Сделайте это, и вы дадите ему шанс. Как жестоко. Э-э, может быть. Э-э, у меня сложилось впечатление из того, что мы сделали до сих пор, что ему будет сложно. О, это забавно. Он пытается добавить текст, и делает это с помощью замены строки. То есть ему нужно выяснить, что находится в конце файла, чтобы понять, что добавить и куда добавить. Э-э, как Builders тестирует Columbus не по порядку. Отличная работа. Он оставил себе хорошие инструкции на будущее. Использовать решетку для запоминания сочетания клавиш для быстрого добавления в Claude MD. Что это значит? Что он пытается мне здесь сказать? Это предложение у меня не понимается. Э-э, хорошо. Теперь он проверяет, что Builder — это клон, копия, потому что он просто перемещен. Э-э, Builder за Builder. клонировано. Я не думаю, что это на самом деле проверяет копирование. Оно думает, что проверяет копирование, но это не так. Эм, хорошо. Круто. Да, именно. Не сработало. Круто. Э-э, нет. И тогда я не хочу, чтобы оно отлаживалось на этих файлах. Хорошо. Нам придется, нам придется сказать ему, чтобы он собрался с силами. Хорошо, поскольку мы близки к автоматическому сжатию, я думаю, что я собираюсь сделать следующее: здесь, это сказать ему зафиксировать изменения, потому что мы почти в конце контекстного окна, и я не хочу, чтобы у него был контекст при написании сообщений коммита. Эм, э-э, давайте зафиксируем то, что у нас есть на данный момент, пожалуйста, или кто-нибудь в чате предложит быть придурком. Фиксировать, э-э, конечно. Давайте попробуем. Давайте посмотрим, насколько хорошо оно следовало инструкциям о том, как писать сообщения коммита. « Wibbling» тоже кажется неподходящим словом. Э-э, хорошо. Что здесь написано? Добавить типобезопасность Конструкторы углов ленты для ориентации вращения. Существующий конструктор ленты принимает три неверных параметра. Сделайте их неуязвимыми. Да, это нормально. Эм, да, конечно. Контекст оставил автоматическое сжатие 3%. Отлично. Оно зафиксировано. Эм, теперь давайте выполним команду `get fetch agentic`, чтобы у меня была резервная копия где-то

еще, а затем выполним команду `compact` и посмотрим, насколько хорошо она сможет продолжить с момента сжатия здесь, потому что я хотел сказать, что предыдущий коммит git немного неверен, эм, в том смысле, что нужно избегать явных производных `clone` и исправить слишком длинный заголовок коммита. Но я думаю, это единственные две вещи, верно? Например, если мы выполним `show-p agentic main`. Эм. О нет. Вероятно, он также не выполнил ` cargo format`, как я предполагаю. Что произойдет, если я выполню `cargo format all`. О, `cargo format get diff`. Да, сброс жесткого состояния. Хорошо. Так что нам придется указать ему сделать и это. Эм, последний коммит в Git содержит изменение, которое требует некоторых корректировок. Эм, заголовок сообщения коммита слишком длинный. Эм, типы маркеров... интересно, нужно ли мне указывать, какие именно типы маркеров? Думаю, я просто назову новые типы маркеров и посмотрю, понимает ли он, что новые типы маркеров не должны ничего выводить, и вместо этого построитель должен иметь ручные реализации производных трейтов, чтобы нам не требовалось выводить на вложенные типы. И наконец, формат Cargo не был запущен. Эм, это также следует отметить в claw. min, чтобы в будущем вы помнили делать это автоматически. Вперед. Формат Cargo не очень удобен. Мне это нравится. Будет интересно посмотреть, как он будет работать после сжатия. О, я приближаюсь к лимиту использования. О нет. Хорошо. Значит, только с этими двумя функциями мы приближаемся к лимиту использования профессионального плана. Болезненные ощущения. Вау. Чэд наслаждается. Сложно, но мы используем многоагентную архитектуру, где у нас есть один суперагент и Клод. Это действительно смешно. Эм, как обстоят дела с ручными изменениями между запросами? Я не уверен. Мне кажется, это может запутать контекст. Эм, это Кромагин. Я ненавижу всё это. Продолжайте. В смысле, вы правы. Эм, эта фигня ни на что не годится, кроме TypeScript. Возможно, примеров кода на TypeScript больше, но его сложнее освоить. Например, в TypeScript меньше странных вещей, о которых нужно знать. Он сбрасывается в 21:00. Это через 45 минут, если предположить, что здесь правильный часовой пояс. Эм, такие вещи, как форматирование, могут быть несколько проблематичными, потому что контекст и сами файлы рассинхронизируются, и это может вызвать проблемы. Лучше делать это только после создания новой сессии. Интересно. Ограничение скорости воспроизведения влияет на атмосферу. Это нарушение прав человека. Вау. Вау. Это правда. Это Интересный момент, о котором я не подумал, — запуск команды `cargo format` в середине сессии может быть проблемой, потому что контекст предполагает, что файл не изменился. Я ненавижу работать с Rust. Это вызывает негативные эмоции. Забавно. Ладно. Он делает кучу всего. Что он делает здесь? Где мы находимся? Здесь мы выполнили сжатие. Удаляет автодиск

добавляет клон, копию и отладку. Я бы хотел, чтобы отладочная команда включала информацию о том, для какого типа предназначен построитель. Я думаю, что нужно запустить `cargo format` для форматирования кода. Добавить это в команды разработки. Да, всегда запускайте `cargo format` перед фиксацией изменений, чтобы обеспечить согласованность структуры кода по всей кодовой базе. Меня это устраивает Измените коммит в Git с исправлениями. Заголовок был в порядке, меньше 50 символов. О, не ложь. Это похоже на лису, верно? Это похоже на лису. Да, это 77 символов. Это не 50 Заголовок был в порядке. Меньше 50 символов, а я смотрю на строку в 77 символов. Заголовок больше 70 символов, значит, он превышает лимит. Просто это ложь. Это откровенная ложь. Пожалуйста, исправьте это. Также, давайте выведем имена типов параметров состояния и целевого типа в отладочной реализации. Это было зафиксировано, верно? Да. Хорошо, отлично. Вы правы. Это больше 50. Я просто лгал вам. О, боже, он не может правильно считать символы. Это действительно смешно. Интересно, показывает ли он мне, насколько я близок к лимиту использования? Я пытаюсь посмотреть сейчас в интернете, например, на своем сайте Claw AI, но он не показывает мне, сколько из моих ресурсов я использовал. Есть ли где-нибудь, где я могу увидеть, насколько я близок к своему лимиту? Политика использования, например, каков лимит на количество токены? Потому что таким образом, я думаю, мы сможем просто вычислить, сколько токенов мы использовали для этого, а затем на основе этого вычислить стоимость. Это бесполезно. Хм, хорошо, что я могу просто беспорядочно прокручивать экран телефона, пока это происходит Извините за это. Я думаю, что в отладочной реализации следует исключить поля, которые еще не были установлены. О, это здорово. Мне это нравится. Давайте сделаем так. Э-э, 77 символов — это слишком длинно. Да. Хорошо. Исправьте это. Круто. Что еще оно сделало? Э-э, но... О, понятно. Сначала оно хочет моего подтверждения. Это нормально. Э-э, я думаю, это динамически зависит от нагрузки на их сервер. Вероятно, поэтому они вам и не говорят. Интересно. Может быть. Есть ли токены с косой чертой? Нет. Хорошо. На самом деле, давайте сделаем так, чтобы отладочная реализация также выводила только те поля, которые были установлены в соответствии с состоянием на данный момент. Мне действительно любопытно, насколько мы близки к... Этот лимит использования. Меня вот-вот выкинет, или это что-то вроде: « Да, у нас есть ещё один, мы можем закончить это изменение.

О, да, смотрите, здесь файлы были изменены с момента прочтения либо пользователем, либо llinter». Так что, я думаю, это недостаток формата Cargo, верно? Хорошо, давайте посмотрим, что там есть. Реализовать отладку цели для потребностей в рыскании, потребностей в тангаже, включает рыскание, потребностей в крене, включает рыскание и тангаж. Это близко. Но я хотел также включить имя цели, что, как мне кажется, означает, что нужно использовать, э-э, имя типа. Да, вот это. Но полезно ли это? Я не уверен, потому что в итоге получается описание типа, которое можно назвать «наилучшей попыткой», а это значит, что тип может быть очень длинным. В качестве альтернативы, он мог бы исчерпывающе перечислить все комбинации потребностей, рыскания и ориентации, потребностей, рыскания и вращения, что кажется ненужным. Я думаю, тип на самом деле относительно хорошо известен. Так что важны только значения. Так что, я думаю... Меня устраивает нынешнее состояние. Хорошо. Тест отладки показывает только установку поля для каждого состояния. Отлично. Затем он обновляет тесты ориентации, чтобы они были одинаковыми. Запускает тест. Теперь ему также нужно запустить Cargo format. И у нас закончился лимит использования. Ваш лимит сбросится в 21:00, то есть через 37 минут. Отлично. Я не собираюсь сейчас переходить на Max. Это кажется чрезмерным. Эм, хорошо. Итак, у нас есть git diff. Давайте запустим Cargo format. Это нормально. Эм, ой, но мне нельзя делать коммиты здесь. Мне нужно сделать это, а затем я получаю commit amend. Ой, ой. Нажимаю commit amend. Что такое commit-f? Но я просто хотел сохранить тот, который был. Хорошо. Editor equals get log get fetch aentic. Хорошо. Ну, я думаю, мы не продвинемся далеко. Эм, agentic main, но у нас есть... Это забавно, на самом деле. Итак, помните, как я сказал, что я думаю... Мы справимся с двумя из четырёх? Мы справились ровно с двумя из четырёх, а потом у нас закончились токены. И это заняло у нас сколько времени? Сейчас 8:30. Мы начали с 6 из-за беспорядка. Так что 6 было 7:30. 8:30. Что я... что я говорю? 6 7 8 8:30. То есть 2 с половиной часа. Эм, 2 с половиной часа использования. Мы выпустили две функции. И я чувствую, что... Ладно, вот мои рассуждения. Я не думаю, что это было быстрее, но и не думаю, что намного медленнее. Эм, это также, вероятно, написало больше тестов, чем я бы сам удосужился написать, что хорошо, верно? Это означает, что мы получили лучшие результаты. Конечно, написали лучшее сообщение коммита, хотя оно немного многословно, я думаю, на мой вкус. Эм, я думаю, я мог бы сказать ему, что мой вкус немного другой. Тот факт, что у меня закончились Интересно, что с токенами всё не так уж и сложно, потому что я не думаю, что мы сделали что-то особенное. Мы даже не дошли до того, что, как мне казалось, было сложнее. Но в целом всё прошло неплохо, правда? Ощущение такое, что ничего особенного не застряло, но при этом программа, по сути, нуждалась в моих указаниях Переключитесь на Gemini Cly. Хотя я слышал, что Gemini Cly намного хуже. Вы делаете это с флагом «небезопасно, делайте что хотите»? Нет, я просто запускаю программу

. Я вам покажу. Просто запускаю её напрямую, а затем позволяю ей запрашивать у меня разрешение. Это не занимает много времени. Обычно я просто принимаю запрос и запоминаю, например, для грузового дока, что всё в порядке, просто помню, что она может это сделать. Да, два из четырёх — это не значит, что она не сможет сделать остальные, верно? Так что, теперь мы немного умнее, чем были раньше. Два других варианта — сделать вектор общим для скорости, поэтому этот вариант на самом деле намного сложнее, если вы посмотрите на тип вектора. В настоящее время тип вектора является общим только для той системы координат, в которой он находится. Но я хочу, чтобы у вас была возможность иметь вектор, который содержит не метры, а, например, метры в секунду или м/с², потому что это ускорение. Вероятно, вы не сможете использовать вот это в качестве ускорения. Хотя, возможно, и сможете. Возможно, вы могли бы использовать вместо этого маркеры. Но я представлял себе, что мы будем использовать здесь, например, ускорение. Итак, в OM единица кодируется следующим образом: вы задаете ей измерение, например, такое, а измерение — это ISQ, а ISQ — это Международная система величин, которая имеет несколько различных свойств, я полагаю, это измерение длины или несколько различных измерений: длина, масса, время, электрический ток, термодинамическая температура, количество вещества, светимость, интенсивность и тип, и каждая единица может быть Выражено через эти величины. Например, метры — это длина в степени один, а все остальные — в степени ноль. Метры/с — это длина в степени 1. Время в степени минус один, потому что оно делится на секунды. Все остальные равны нулю. Ускорение — это длина в степени 1, умноженная на минус 2. То есть м/с². И вы можете видеть это здесь, поскольку ускорение является матрицей линейной зависимости, где длина, которая была первым параметром, — это P1, то есть положительный, следующий параметр — это то, что я только что сказал, — масса, то есть масса — это z для 0,0, а время — это n2 для -2, и поэтому размерность для ускорения — это конкретное представление. Поэтому я подумал, что мы можем сказать здесь, что это то, как это называется в линейной зависимости, t для времени. Таким образом, вы можете задать здесь t, которое обычно равно z0, но этот вектор — это то, что вы можете построить вектор, который, например, находится в плоскости ne, но который имеет n1, и это было бы, знаете, мы могли бы даже иметь псевдоним типа для этого, верно? Так что это был бы вектор, вектор скорости, вектор ускорения, например, вот так, а вектор ускорения был бы n2, и тогда все методы для вектора были бы обобщенными по второму параметру. Единственное место, где второй параметр имеет значение, это конструктор и место, которое позволяет получить значения. Так что, я думаю, мы могли бы сделать это. Но это определенно более сложное изменение, и я хотел бы его предложить, но у нас не было времени. Может быть, мы сделаем это, еще один поток, подобный этому, и попробуем внести это изменение и посмотрим, насколько хорошо оно себя покажет. Итак, это было второе изменение, которое я имел в виду. Последнее — это N-векторы или ECI, что еще сложнее. N-векторы — это другой способ представления местоположений на Земле. Я упоминал, что есть EIF, это координаты XYZ, от ядра Земли к основной радиации. Ось Z, широта, долгота, ноль, э-э, и различные другие оси. Другой вариант — координаты GPS. Широта, долгота, высота — это положение на сфере или эллипсоиде. n-векторы — это интересный третий способ выражения координат: вы выбираете точку на Земле, которую хотите описать. Вы берете нормальный вектор — единичный нормальный вектор к этой точке. Это вектор, направленный перпендикулярно поверхности Земли во всех направлениях и имеющий единичную величину, и вы помещаете его в точку, где находитесь. Оказывается, это дает вам взаимно однозначное соответствие между каждой позицией на Земле и n-векторами, а затем вы кодируете

компоненты n-вектора в e, и это ваш n-вектор. Преимущество представления n-векторов заключается в том, что оно позволяет вам, например, вычислять широту и долготу, преобразовывать n-векторы в широту и долготу очень просто. Преобразование между e и WGS84 на самом деле очень сложное. N-векторы обладают свойством иметь систему координат XYZ. Но у них также есть простые преобразования. Другая проблема с GPS-координатами заключается в том, что на таком большом расстоянии существует сингулярность на полюсах. Например, когда вы переходите от широты, представьте, что у вас нулевая долгота, а широта продолжает расти: сначала 89, потом 90, потом снова 89, но внезапно долгота меняется на 180 вместо нуля. Таким образом, вы получаете огромные сдвиги значений даже при небольших изменениях положения. У N-векторов такой проблемы или такого свойства нет. Поэтому было бы здорово добавить поддержку N- векторов в Squaba. Но для этого, я думаю, потребуется гораздо больше знаний от LLM. Но мы до этого не дошли. Но, возможно, мы проведем еще один стрим, когда я буду больше знать о том, как управлять этими вещами, что, как мне кажется, я уже знаю по сравнению с тем, что я делал в начале этого видео. Думаю, пока что опыт был неплохим. Я не чувствую себя удивленным, может быть, немного, может быть. Возможно, понимание того, что я, по сути, учу его применять более мелкие шаблоны, здесь полезно, но это также тот случай, когда мне не ясно, сможет ли агентный ИИ улучшить эту часть, верно? Например, мне часто приходилось указывать, какие шаблоны использовать или какие изменения внести. И это само по себе неясно для меня как шаблон. Я не знаю, как можно улучшить языковую модель в этом или агентный ИИ в этом плане. Но, возможно, роль инженеров-программистов здесь в том, что это то, в чем мы хороши, а затем они занимаются применением шаблонов. Буду ли я использовать это гораздо чаще? Возможно. Было ли это лучше, чем писать код самому? Я не уверен. Мне очень нравится писать код. Так что я не знаю, было ли это лучше, но это было по-другому, и мне нравится по-другому. Давайте, прежде чем мы закончим, возможно, зададим вопросы о том, как мы сюда попали, какой опыт у нас есть на данный момент. Э-э, мой план состоит в том, чтобы отправить эти изменения в виде PR в Squaba. Так вы сможете подробнее ознакомиться с изменениями там. Э-э, я отправлю их как два отдельных MRS, потому что нет причин делать их одинаковыми. Э-э, чтобы люди могли их посмотреть. Если вы смотрите запись этого, конечно, то PR уже будут доступны в репозитории Squaba, и, надеюсь, они будут объединены, если только у людей не будет много замечаний по этому поводу. Э-э, но вопросы по всему этому процессу или вопросы, на которые вы хотели бы получить ответы о моем опыте, э-э, задавайте. Я пытался параллельно работать над кодом во время трансляции, пытаясь сделать ту же работу, что и сегодня утром, и это было ужасно. Приходилось постоянно что-то исправлять, и все равно все получалось неправильно. Да. То есть, опыт здесь был таким, что мне приходилось постоянно все исправлять. Но в то же время, я не чувствую, что это... э-э... это означало... В итоге получилось медленнее, чем если бы я сделал это сам, но и быстрее тоже не стало. Мне вот интересно, а не является ли целью повышение квалификации инженеров-программистов? Представьте, что у вас нет такого же опыта работы со многими из этих узоров, как у меня. Тогда, если бы вы использовали здесь агентное программирование, получили бы вы тот же результат, что и я, или же в итоге получили бы что-то, что всё ещё было бы хорошей идеей, правильной реализацией? В общем, направило бы это вас в нужное русло, или же оно просто выбрало бы первый попавшийся шаблон, который примерно соответствовал бы вашим ожиданиям, то есть, скорее, создавал бы нужную атмосферу, а вы бы просто сказали: «Ну, наверное, так и есть», и оно бы зафиксировало результат, и вы бы на этом успокоились. Эм, я думаю, мне не стоит беспокоиться, но я не уверен, в какой степени это делает людей лучшими программистами, чем они были раньше, или заставляет их писать более качественный код, чем они писали раньше. По крайней мере, мой опыт здесь показал, что мне пришлось рассказать системе о том, что ей нужно улучшить. По крайней мере, пока это не выявило закономерностей, которые я упустил, или вещей, о которых мне следовало бы подумать. Эм, я бы предпочёл, чтобы две последние функции были реализованы в виде обычных потоков, а не с помощью кодирования в стиле Vibe.

Эм, возможно, я думаю, что проводить их в формате стримов тоже было бы интересно. Я не думаю, что вы получили бы много других интересных идей, что, возможно, является любопытным наблюдением. Например, когда я делаю обучающие видео, я стараюсь научить людей вещам, которые не всегда очевидны, и в каком-то смысле мне пришлось сделать то же самое и с агентом: объяснить не просто применение шаблонов, а, например, подумать: «А что, если мы сделаем это? » или «Это будет иметь следующие недостатки? » Думаю, вы упускаете что-то вроде синтаксиса Rust или того, как структурировать данные в Rust. В некоторых местах я быстро просматривал результаты сравнения файлов и думал: «Да, выглядит вполне разумно». И вы упустили возможность увидеть, как это получилось, и теперь я понимаю, как это произошло. Возможно, часть этой информации теряется, но это, вероятно, лучше отражает выводы, полученные знания, ключевые отличия или важные наблюдения, которые я сделал в процессе внедрения. Он обладает энциклопедическими знаниями, но часто не знает, как эффективно их применять Ага. Это одновременно похоже и совершенно отличается от работы штатного младшего инженера. Это правда. Да, отчасти это связано с тем, что мне очень нравится писать код. Таким образом, тот факт, что программа пишет код за меня, если только она не делает это намного быстрее, что в данном случае, я не уверен, действительно ли это так, из-за всех запросов, которые мне приходилось отправлять, в итоге оказался быстрее, чем если бы я написал код сам. Эм, на секунду TypeScript — это потрясающе. Но то, что я там делаю, в основном связано с уже решенными проблемами или просто с перетасовкой данных. Я бы этого и ожидал, верно? Во-первых, что касается фронтенда, я ожидаю гораздо лучшего качества. Там больше примеров, и всё более единообразно, но также встречаются вещи, которые являются просто копированием, по сути, полных шаблонов, уже реализованных в других местах. Я ожидаю, что он будет действительно хорошо справляться со своей задачей и сможет делать это без множества промежуточных подсказок. Хм, я уверен, что вы не смогли бы написать документацию и тесты такого же уровня, с той же скоростью и глубиной проработки, за то же время. Эм да. Итак, как я уже отмечал, я думаю, что написал бы меньше тестов, чем написал. Я думаю, это правда. Эм, и в этом смысле это было удачное применение. Что касается документации, мне кажется, там написано больше слов, чем я бы написал сам. Эм, но я не думаю, что там было написано больше контента, чем я бы сам включил. Но это, конечно, всего лишь предположение, не так ли? А вам удалось протестировать функцию суб-агента? Нет, я этого не делал. И я думаю, что если бы я попытался использовать субподрядчиков, то бюджет закончился бы еще быстрее. М-м, как человек, не являющийся программистом, могу ли я сказать, что эти инструменты предоставляют доступ к возможностям, которых раньше не существовало? Я полностью согласен с этим, особенно в тех случаях, когда можно убить противника с одного -двух ударов. И я думаю, это справедливо для многих задач визуализации данных, анализа веб-сайтов, для многих подобных вещей, где люди обычно хотят чего-то очень похожего, если не идентичного тому, что было создано раньше, а теперь это можно сделать, не зная, как создавать программное обеспечение. Я считаю, что это чрезвычайно ценно. И один из главных плюсов здесь, я думаю, знаете, когда я говорю, что я скептически отношусь к агентному ИИ, это не значит, его полезности. Я думаю, что он действительно полезен во многих ситуациях. Вопрос в том, насколько это полезно для тех дел, которыми я занимаюсь большую часть дня, верно? И здесь мне менее ясно, но что касается возможности для людей, не являющихся инженерами-программистами, создавать больше программного обеспечения и использовать его в качестве инструмента в своем арсенале. Абсолютно, на 100% невероятно полезно. Эм, на мой взгляд, если вы делаете это самостоятельно, вы больше сосредоточены на бизнес-логике, чем тратите умственные ресурсы на обдумывание того, как настроить подсказки так, чтобы ИИ понимал вас так же, как и вы. Эм, я думаю, что на самом деле нахожусь в странном положении, потому что, поскольку я делаю это на стриме, если бы я сам писал код, я бы все равно говорил вслух о том, что пытаюсь сделать. Поэтому я по-прежнему буду пытаться сформулировать то, чего я хочу добиться, просто голосом, а не профессиональными словами. Поэтому я не думаю, что

в моем случае разница будет настолько большой. Я считаю, что в целом, когда пишешь что-то, например, код, не стоит вслух говорить о том, чего ты пытаешься достичь. Таким образом, обдумывание вопросов оперативного проектирования станет своего рода дополнительным этапом, которого вам иначе не пришлось бы выполнять. Хм, давайте также учтем, сколько энергии, вероятно, потребовалось для внесения этих изменений. Да, я имею в виду, что это еще один очень важный аспект, который мы еще не обсуждали. Речь идёт не только о денежных затратах на эксплуатацию этого устройства, что, как я понимаю, является одним из примеров профессионального плана, но и об экологических издержках, связанных с оборудованием, необходимым для его работы, а также с электроэнергией, необходимой для его работы и охлаждения. Здесь явно присутствует множество скрытых затрат, и это часть компромисса: если я чувствую, что это не сильно увеличивает мои собственные затраты, стоит ли это всех этих расходов? Стоимость жизненного цикла практически равна нулю. Эм, мне также кажется, что здесь есть что-то такое, что произошло бы, если бы я мог меньше на это провоцировать. Можно утверждать, что я мог бы заниматься другими делами, пока думаю, но в данном случае у меня сложилось другое мнение. В каком-то смысле я надеялся, что так и будет, и я смогу запустить процесс, чтобы он автоматически запускался. Это длилось бы минут десять, а потом я мог бы вернуться и, может быть, немного подкорректировать. По сути, это фактически завершило разработку этой функции. На самом деле это было не так. Может быть, мне стоило больше доверять этому и отпустить ситуацию, больше полагаться на интуицию. Но я не чувствовал, что это правильный путь. У меня не сложилось впечатления, что это сработало бы. Эм, но если бы это было так, и, возможно, это было бы так, с подсистемами и всем прочим, если бы я поручал ему более крупные задачи, возможно, я мог бы потратить свой мозг на что-то другое, пока он делает это, и тогда, конечно, вы получаете параллелизм, настоящую многопоточность, а это тоже довольно ценно Эм... я не спрашивала об этом, о том, что ты пропустила. Это правда. Это был бы хороший вопрос. Но у меня также закончился контекст для обеих вещей. В обоих случаях я вырвал тему из контекста, прежде чем дело было доведено до конца. Эм, по моему опыту, вы не станете лучшим программистом, если уже не являетесь таковым. С помощью практики вы сможете значительно ускорить процесс. Я не уверена, правда ли это, потому что... оно ведь знает о закономерностях, о которых вы не знаете. Если у вас нет очень большого опыта, я предполагаю, что эта программа знает множество закономерностей, о которых вы не знали. Менее ясно, помнит ли оно о необходимости их применения. Но я предполагаю, что в каком-то смысле, подобно тому, как люди, смотря мои видео, могут сказать: «О, я не знал, что это закономерность. так можно делать». Я могу представить себе, как, увидев результат работы агентного кода, испытываешь то же самое чувство, что и потом, когда понимаешь: « О, я знаю, что теперь это можно сделать на Rust». Ну, в общем, я ожидаю, что вы сможете извлечь из этого урок. Насколько хорошо это будет работать, я не уверен, потому что, кажется, это больше ориентировано на то, чтобы внести за меня изменения, а также объяснить мне вещи, которые я могу не знать. Но, возможно, вы сможете настроить это прямо в своем облачном хранилище MD или где-то еще. По сути, расскажите мне, например, в конце занятия: «Расскажите о том, чему я мог бы научиться или чему я теперь научился». Эм, да, кто-то здесь упомянул структурную разметку, ролевую игру и другие приемы, которые могут здесь хорошо сработать. Эм, знаете, недавно был хороший пост от Нико Мацакеиса об использовании чего-то вроде... как это называется? Сократовский метод, по сути, предназначен для обучения ИИ тому, какую роль он должен играть во взаимодействии. Это может быть интересно. Другой вариант — это идея помеченных комментариев, когда вы указываете агенту оставлять комментарии для себя в коде на будущее, чтобы у него было множество опорных точек в коде, к которым он сможет позже обратиться. И я думаю, это может быть действительно интересным способом посмотреть, как ситуация улучшится. Или же степень, в которой это помогает. Эм, кажется, я могу вернуться к этому виду. Эм, исторически сложилось так, что то, что вы транслируете, — это процесс написания кода. Да, я не думаю, что откажусь от стримов, где я пишу код, отчасти

потому, что мне это очень нравится, а отчасти потому, что я считаю, что на таких стримах можно многому научиться, чего нельзя получить на подобных сессиях. Эмм, тем не менее, я все еще считаю, что это было полезно. То есть, это в некотором смысле вопрос к вам, зрителям, верно? А была ли эта информация вам полезна? Но мне кажется, что это учит чему-то другому, или, может быть, выделяет другой аспект, потому что ты больше узнаешь из подсказок и из того, что программа делает, что она выбирает делать и что ей следовало бы сделать вместо этого. В то время как в программировании, я думаю, большая часть работы связана с написанием большого количества кода. Эм, я думаю, они разные. Я не знаю, хуже ли это. Эм, да, мы обсуждаем с ним возможные решения, просим его написать тест в документации. Мне кажется, это полезная информация. И опять же, как я уже упоминал, я думаю, что именно написание тестов принесло мне наибольшую пользу по сравнению с тем, что я бы сделал сам. Эм, и было бы интересно посмотреть, что получится, если бы я сам написал большую часть реализации, а потом сказал: « Эй, пожалуйста, протестируйте это». Это также был бы интересный вариант использования ИИ в качестве партнера по программированию, и, возможно, когда-нибудь это стоило бы попробовать. Попробуйте более короткое описание. Я попробовал там несколько довольно коротких вариантов. Эм, давайте посмотрим. Я просто просматриваю чат. Посмотрите, нет ли чего-нибудь особенно полезного, что можно было бы сделать или обсудить. Эмм, внедрение идей из научных работ. Возможно, вы могли бы использовать агентный ИИ, чтобы, следуя спецификации статьи, написать реализацию, например, на Rust. Возможно, стоит попробовать. Не думаю, что стал бы делать это во время стрима, но попробовать стоит. Эм, я бы никогда не хотел, чтобы ИИ писал за меня код и разрабатывал архитектуру решений, потому что это то, что мне доставляет удовольствие. Ммм, да и нет. Верно? Если, конечно, вам не обязательно всегда использовать Genti или всегда писать код самостоятельно. Вы могли бы подсчитать баланс, верно? В тех случаях, когда вы не хотите писать код самостоятельно, вы используете для этого агента. Думаю, в данном случае хорошим примером являются такие вещи, как тесты. А можно даже сделать наоборот, верно? Можно сказать: «Вот функция, которую я хочу добавить». Напишите мне, и вот как я хочу, чтобы выглядел интерфейс. Напишите мне кучу тестов, а потом я напишу реализацию. По сути, вы получаете разработку, управляемую тестированием, или разработку, управляемую поведением, без необходимости заниматься утомительной работой по написанию определений тестов и поведения. Это был бы интересный способ попробовать сделать это тоже. Эм, мы определенно находимся на начальном этапе изучения того, как эти инструменты взаимодействуют с нами. Часто мы забываем, что в аббревиатурах HCI или UI буква I может быть как положительной, так и отрицательной. Это правда. Я думаю, что Клод — это большой шаг вперед по сравнению с тем, как мы раньше взаимодействовали с агентами, что больше походило на автозаполнение или редактор, и сейчас кажется, что стало лучше, но неясно, что это конец пути. Полностью согласен с этим. Один из моих любимых способов использования LMS — это написание простого, незамысловатого кода, который работает так, как мне нужно, и последующий вопрос о том, как сделать его проще или более понятным. Это тоже классный способ его использования, правда? Таким образом, получается что-то вроде Clippy, но немного менее строгого и в большей степени основанного на атмосфере, например: «Хорошо ли выглядит этот код? » Мне было бы любопытно узнать, как часто это приводит к ошибкам, или, в каком смысле, каков вкус Клода в программировании? На что это указывает, а на что нет? Что касается выхода за рамки контекста, что бы произошло, если бы кодовая база была намного больше? Поэтому я не думаю, что большой размер кодовой базы сильно повлияет на ситуацию, потому что, когда вы запускаете Claude, он фактически проходит по всей вашей кодовой базе один раз и создает облачный MD, который пытается быть своего рода сводкой вашей кодовой базы, чтобы при последующих запусках ему не нужно было читать все файлы. Именно поэтому существует ограничение на то, сколько данных он может прочитать из файла за один раз, и механизм для этого заставляет его проходить по файлам, а не пытаться прочитать все целиком. И я думаю, что важная часть этого заключается в том, чтобы не слишком сильно загрязнять контекст. Каждый раз, когда

сборка завершалась с ошибкой, контекст программы полностью удалялся. Тысячи строк кода C, содержащих ошибки, каждый раз съедали 4% кода. Да, это довольно тяжело. Хм, а время, затраченное на написание кода, вообще является хорошим показателем для оптимизации? Я могу предположить, что если вы позволите агенту это сделать, то позже вам придётся доплатить, поскольку вы не знакомы с этим кодом. Ага. В каком-то смысле, сейчас не просто время это писать. Время, необходимое для написания кода, примерно такое же, как если бы вы написали его сами, верно? С точки зрения вашей уверенности в этом, а также вашей способности развивать это дальше. Это правда. Думаю, этот временной промежуток легко можно исключить из рассмотрения. Но мне кажется, что в зависимости от того, какой запрос вы перед ним выдадите, он не выдаст много кода, который вы не просматривали. Но, может быть, это потому, что у меня недостаточно взаимопонимания, верно? Например, здесь у меня такое ощущение, что я в каком-то смысле прочитал весь написанный им код. Эм, но это не всегда может быть так. Хм, я не уверен, что это тот же объем контента, что и просмотр ваших стримов, где вы сами пишете код, например, образовательный контент. Эм, я думаю, это, вероятно, правда. Написание кода самостоятельно, на мой взгляд, больше подходит для программистов, потому что включает в себя как написание кода, так и использование Rust, а также архитектурные решения. Здесь вы получаете последнее, но не первое, зато здесь вы получаете больше информации о том, как бы я обращался к агенту или, может быть, если на секунду отвлечься от агента, как бы я разговаривал с человеком, который моложе меня, о том, как реализовать ту или иную функцию. А может быть, это и пригодится. Это контент другого рода. Неясно, меньше ли в этом контенте. Возможно, здесь меньше контента, который вам действительно нужен. Эм, люди открывают 100 000 запросов на изменение строки, написанных Клодом. Ты определённо недостаточно хорошо взаимодействуешь с окружающим миром. Справедливый. Я — виновный по предъявленному обвинению. Но в то же время, я думаю, мне удалось создать нечто полезное, а не просто набор бессмысленных звуков. Так что, возможно, это и хорошо. Эм, хорошо. Думаю, это значит, что мы подошли к концу. Думаю, мы уже обсудили большую часть вопросов в чате. Мы сделали два фильма. Я думаю, я сделаю еще одно видео, где, возможно, мы продолжим обсуждение двух других тем, или, может быть, я реализую одну из них, а затем спрошу Клода обо всех своих ошибках. Ещё один момент, похожий на тот, что здесь был, когда мы спросили Клода: « Что именно в этом коде нетипично? » Я подумывал сделать то же самое для более крупного кодового набора, который, как я понимаю, довольно громоздкий. Я, наверное, лет шесть, семь или восемь назад писал бота для Slack. Эм, это отсылка к моим ранним работам над Rust. Я уверен, что это плохо по многим причинам. Было бы забавно бросить Клода за дело и сказать: «Эй, сделай это намного лучше». Просто перегруппируйте неудачные тесты. Например, нужно улучшить его разными способами и посмотреть, что получится. Эм, так что, вероятно, будет какое-то второе видео по программированию VIP-программ, но я пока точно не знаю, какой структуры оно будет. Эм, а пока, спасибо за просмотр. Надеюсь, это было интересно. Надеюсь, вам понравилось. И наконец, слово от спонсора этого видео. Пойдем. Спонсором сегодняшнего видео и первым спонсором канала является компания Hudson River Trading. HRT — это компания, занимающаяся количественной торговлей, использующая новейшие достижения в области машинного обучения, высокопроизводительных вычислений и системной инженерии для совершения сделок на более чем 200 мировых рынках. Они гордятся своей развитой инженерной культурой и неустанным стремлением к повышению производительности. HRT — это компания, которая в основном использует языки программирования C++ и Python, по крайней мере, на данный момент. Но то, что изначально привлекает людей к Rust, — это именно то, с чем они сталкиваются ежедневно, углубляясь в самые нижние уровни своего аппаратного и программного обеспечения, включая оптимизацию набора инструкций и настройку компилятора, и всё это при соблюдении строгих требований к корректности. В настоящее время они набирают сотрудников в офисах по всему миру. А если вас заинтересовало участие, перейдите по ссылке в описании видео, чтобы узнать больше.