Ошибки в коде 90% программистов
HTML-код
- Опубликовано: 16 июн 2024
- В гостях у Желтого клуба Александр Митрофанов из Спортмастер Лаб. Показываем типичные ошибки 1С программистов при заполнении и проверке введенных данных.
Вопросы с виду простые, но разработчики не задумываются о неочевидных правилах. Александр показывает типичные ошибки 1С программистов и рассказывает, как правильно проверять данные, чтобы сделать код выразительным и консистентным, а не пюрешкой, размазанной по конфигурации 😂
Во второй половине стрима говорим, как разрабатывают на 1С в Спортмастер Лаб.
НАВИГАЦИЯ
00:00 - Вступление
01:04 - Чем по сути занимается 1С разработчик
01:58 - Последовательность событий в 1С. Заучить как таблицу умножения.
05:45 - Как правильно проверять введенные данные
09:20 - Почему вызывается ОбработкаПроверкиЗаполнения в модуле объекта
13:27 - Как проверить заполнение табличной части
27:38 - Итого: правила обработки проверки заполнения
28:27 - Настройка подсветки незаполненного значения в табличной части
42:19 - Проверка остатков
59:53 - Как проверять заполненность справочников
01:06:53 - Обработка Заполнения
01:25:00 - Как устроена разработка в Спортмастер Лаб
01:33:50 - Как устроиться на работу в Спортмастер Лаб
01:37:50 - Демонстрация Jira и Sonarqube
01:50:00 - Каких разработчиков ждут в Спортмастер Лаб
01:57:39 - Об оформлении кода
02:04:00 - Финал
ДОП. МАТЕРИАЛЫ:
Если хочешь работать в Спортмастер Лаб, то пиши Александру в тг: t.me/AGMitrofanov
База: cloud.mail.ru/public/8eMf/f2d...
Презентация: cloud.mail.ru/public/WxUa/ynE...
Последовательность событий:
its.1c.ru/db/pubdevguide83/co...
Стандарт по обработке проверки заполнения:
its.1c.ru/db/v8std/content/46...
Обработка заполнения:
its.1c.ru/db/v8std/content/39...
Условное оформление (почему кодом)
its.1c.ru/db/v8std/content/71...
#1c #кодна1С#красивыйкодна1С
==========
Информационные площадки "Жёлтого клуба":
Телеграмм канал: t.me/+h2Ipfl1Gdms3OGYy
Телеграм чат: t.me/yellowclub_vrn
Группа ВКонтакте: vk: yellowclub_official
Подписывайся на канала Желтого клуба, чтобы не пропустить интересных гостей
/ @yellow_club
Тайм-коды
0:00:00 Начало
0:01:00 Условная разбивка задач
0:02:00 Последовательность событий при проведении документа (ссылка в описании)
0:06:30 Проверка заполнения. Как не надо делать
0:09:00 ПроверитьЗаполнение(). Как правильно
0:10:25 Для чего обработка проверки заполнения на форме?
0:16:10 Универсальная проверка для документов (как в типовых)
0:27:30 Подведение итогов по проверке заполнения
0:30:00 Подсветка с помощью условного оформления
0:34:00 Добавить простой элемент условного оформления
0:38:45 Почему условное оформление стоит дело программным кодом
Побольше бы таких гостей и таких стримов) И очень хороший ведущий, кстати!)
Отличное количество полезной информации в единицу времени. Спасибо.
Обязательно к просмотру всем программистам 1С. Хорошо излагает мысли.
Круто, когда то этого прям не хватало! Классный обзор ) Очень толковое видео для начинающих
Рад, что понравилось
Не вздумай так писать на работе)))
Для начинающих это вы загнули. Многие middle не знают кучи из обслуженного. Здесь с точки зрения стандартов информация и практики подаются уровня минимум middle+ ~ senior
Спасибо за Ваш труд. Темы про чистый код и грамотное проектирование актуальны всегда.
Действительно качественный контент, спасибо Вам за труды!
Рад, что понравилось
Полезное видео, спасибо😀
Спасибо за видео, отличный гость!
Рад, что понравилось
Все досмотрел, сам себя удивил. Интересная тема. Спасибо
Рад, что полезно
супер материал. спасибо 👍
Отличный стрим! Зовите Александра ещё.
Договорились 🤝 рад, что понравилось
Ух, это были довольно напряженные полтора часа. На фоне не посмотришь.
Но все очень грамотно, аргументированно и в целом много полезного, что я буду пытаться внедрять в нашей компании.
да, кайфую от Сонара. Хочется у себя внедрить)
Было бы круто ещё увидеть такого крутого спеца
В большинстве своем человек рассказывает про стандарты разработки. Хорошо если у них реально так построено как он рассказывает и показывает к сожалению далеко не везде так красиво просто потому что веками так сложилось. Понравилось как реализована проверка заполнения. Как проводки. Классно. Надо внедрить, вопрос как привыкнуть к этому нововведению) Думаю человек который пойдет работать в эту компанию не будет задаваться вопросом что надо знать для того чтобы туда попасть. Ты либо знаешь что ты подходишь либо тебе рано.
Тема валидаци очень интересна. Хотелось бы ещё послушать, какие подходы используют для проверок между связанными объектами, а также архитектурные подходы избавляющие от таких зависимостей. Может быть даже Александр что-то посоветуют в комментарии ;)
Классный чел. много полезного. Спасибо.
хорошо основу выдали кратко и доходчиво.
Молодец, понравилось!
Гостю респект, думаю, команда им дорожит)
Есть чему поучиться. Ещё плюс когда объясняют для чего это делается. А не гавно на вентилятор набрасывают
было бы ОЧЕНЬ круто если бы сделал стрим по разбору вакансий на hh например, где бы можно было позвать знающего человека и разбирать детально каждое требование и как к этому двигаться
Классная идея! Осталось найти спикера. У меня есть один на примете
один на собеседовании попросил сделать универсальную проверку с выводом сообщений для любого объекта, регистра )
@@evgeniuxp2evgeniuxp234 чиво? Какую проверку?
@@evgeniuxp2evgeniuxp234 проверку корректности чего именно в этом любом объекте?
Спасибо!
Рад, что понравилось
Добрый день! Спасибо за интересное видео. Скажите, будет ли стрим, посвященный ЗУП?
Неее, мы ЗУП не любим 😁
Хотяяя…. Если найдутся знатоки, то можно
@@yellow_clubа вот зря вы его не любите))) он только с виду страшный, а на деле - просто душка)))
Может может))
@@yellow_clubЯ раньше тоже не любил ЗУП, ну разве что обновлял конфу на замочке. А вот потом начал с ним плотно общаться, и даже сдал спеца
Добрый день.
Подскажите пожалуйста (перерыл весь интернет не нашёл информации): 1С Альфа-Авто, простые формы. Там немного другая последовательность обработчиков событий: сначала ОбработкаПроверкиЗаполнения, а потом ПередЗаписью(Форма) и далее ПередЗаписью(Модуль) ... НО если записываем документ программно, то сразу заходит в ПередЗаписью(Модуль), игнорируя ОбработкуПроверкиЗаполнения (сам проверял отладкой, так и есть). Так как других выходов нет, кроме как запихивать проверки в ПередЗаписью, возникает вопрос, когда в простых формах начинается транзакция, также в ПередЗаписью или в ПриЗаписи? Или может бытт есть возможность делать проверки перед ПередЗаписью)?
При программном создании нужно самостоятельно вызывать проверку с помощью метода ПроверитьЗаполнение
16:33 проверяют имя таблицы по тексту, т.е. имя объекта. А не правильнее ли будет проверять именно по типу метаданных, т.е. ДокументОбъект.Метаданные() = Метаданные.Документы.Реализация? И еще момент, если МассивПроверок пустой за чем дальше продолжать процедуру, логичнее на этом завершить наверное
Да, крутой гость.
Согласен
Что лучше - использовать РазбитьТаблицуПоЗначениюКлюча или обходить результат запроса по группировкам?
Контора в принципе крутая и требования к спецам соответствующие, другой вопрос стоит ли в такую контору идти? По мне так не стоит, у меня был 3х летний стаж в работе где за каждый чих отчитываешься и постоянно записываешь часы в жиру, постоянно формируют эти недельные спринты где на тебя поставили 40 часов хотя по факту там 50+ будет т.д и т.п., плюс часто были переработки из-за того, что премию просто так не получить а лишить её могут прям на изи хотя зп была не шибко то выше чем по рынку.
По сути в этом видео говорится о двух из 5 принципах ООП - это Полиморфизм и Инкапсуляция и подходе DRY(модульность). Раньше принципов ООП придерживались в основном при разработке платформы, а последние лет 5 наблюдаю как все больше этих принципов придерживаются при разработке самих конфигураций и даже заметно использование таких паттернов как посредник строитель и д.р., то есть сильно растет квалификация разработчиков 1С, при том что они в основном разрабатывают в контекте DDD и DSL.
По поводу БлокироватьсяДляИзменения - это свойство не "убирает флаг разделения итогов", правильнее сказать, что оно ставит управляемую блокировку на все поля регистра, также как мы это явно бы сделали и игнорирует сплитер разделения итогов при схлопывании одинаковых строк после их записи в таблицу итогов.
По поводу того что выборку запроса выгрузить в таблицу значений это плохо, то не совсем верно. Все зависит от архитектуры сервера 1С. Если 32х то памяти на одина рабочий процесс 4гб и выгрузка в тз большой выборки может занять всю память процесса и вытеснить из нее остальной кэш, а часть данных которая не поместилась запишется в temp и будет браться из диска, как это проиходит при выборке из результата запроса, а если арх 64х(ос и сервер), то озу на один рабочий процесс измеряется десятками терабайт и и проблемы выгрузка в тз даже большой выборрки уже не вызывает.
Другой вопрос, гораздо более базовый - а необходимо ли выгружать? Если данные в виде таблицы дальше куда-то целиком идут по логике - значит необходимо. А если можно и нужно лишь порционно обработать данные и «забыть» про них после этого, то выгрузку делать не следует.
В заполнении документа не очень хорошо делать прямое заполнение реквизитами входящей структуры, так как там могут быть всяческие специфические типы и прочее нехорошее. В типовых ДанныеЗаполнения.РеквизитыШапки используется, для заполнения шапки документа.
Как у него обозначены условия и циклы? Где это настраивается?
Мне часто попадается творчество, благодаря которому дико тормозит 1с. И это творчество это обращение через точку :)
замеры делал?
@@albrehtdurer557 да, избавление кода от точек с переделкой в запрос приводило к повышению производительности в сотни раз.
По крайней мере на скульной версии платформы.
Блгадаря точке задержка может быть просто чудовищной.
@@MotoCrankshaft ага, если она в цикле и нет кеша предварительно сформированного.
1:58:33 а что за символ он поставил в поле Табуляция? Пробую | но получается прерывистая линия, а у него непрерывная
о, нашел │
есть доп. символы, так сказать. Во времена доси, нужно же было как-то рисовать интерфейс и печатные формы с отчетами красивые) Символ можно вывести по его коду. В любом тестовом поле зажимаете ALT и код символа. Код символа │ 179.
Про "Перечитать". Еще может возникнуть, когда одновременно два пользователя меняют один и тот же документ. Первый изменил, а второму высветилось сообщение с предложением прочитать изменения.
в правильной разработке такого быть не должно, перед открытием надо блокировать данные документа
@@albrehtdurer557да ну? Даже посмотреть не дадите? В 1с по умолчанию принцип как раз таки противоположный тому, что вы написали
@@LosashExote ты понимаешь разницу между посмотреть и изменять? в 1с нет принципа, есть несколько вариантов на выбор разраба
@@albrehtdurer557 а ты понимаешь? Свой коммент перечитай. Не давать зайти в документ когда в него кто-то зашел. Разработчики типовых конфигураций с тобой не согласны.
Как все сложно))
ЗначениеЗаполнено и нормально - это топ 😂
Скажу по секрету - вилка 200-300к. Но требования там запредельные.
Требования мидл\сеньер. Т.е. с нуля нужно 2-3 года опыта, в среднем.
а это где такая вилка?
какие именно требования?
Обработка проверки отрицательных остаток(48:00): Зачем такая сложность , почему нельзя просто получить остатки на ТА по фильтру Склад и Номенклатура из документа ? По сути это же и делается ,только берется старое движение, накладывается новое, объединяется и уже потом фильтром накладывается на остатки... Конечно в последнем запросе не все товары из документа, но каков выхлоп в итоге?
Алгоритм универсален для прихода и для расхода. В случае, если в документе прихода будет удалена строка и вы не прочитаете её из базы, то рискуете получить отрицательные остатки
Спасибо за видео - очень интересно и познавательно, однако заметил ошибку! На 54:40 не хватает параметра в виртуальной таблице РегистрНакопления.ТоварыНаСкладах.Остатки.
Если проверять отрицательные остатки на конец времени, то возможна такая ошибка:
2023-05-01 Приход 10
2023-05-02 Расход 8
2023-05-03 Приход 100
Теперь если удалить документ от 2023-05-01, то ошибки не будет, т.к. остаток на конец времени = 92. Однако остаток на конец дня 2023-05-02 = -8
Это не ошибка, это упрощённые требования. (вопрос в том, что мы контролируем)
Подробнее в телеграмм чате в комментариях к ссылке на ютуб расписывал ответ на такой же вопрос
@@user-ww9oi6fm4x если были такие требования, то да - согласен. В любом случае, вам большое спасибо за видео. Вы - молодец.
А при отмене проведения как отработает код проверки? Набор записей ведь будет пустой, а значит и контроль не пройдет. Значит и отмена приходов может привести к отрицательным остаткам?
Контроль выполняется по измененным записям. В "ПередЗаписью" раннее записанные движения документа. В "ПриЗаписи" - записанные в текущей транзакции. Эти данные группируются по измерениям и, если значение ресурса не равно нулю, то эти измерения попадают в таблицу контроля. По таблице контроля вычисляется остаток. Таким образом, не важно что вы делаете: изменяете запись, отменяете запись набора или добавляете новые записи расхода. Контроль в любом случае отработает корректно и с одинаковым результатом.
@@user-ww9oi6fm4x Способ удаления движений товаров "Удалять автоматически". При перепроведении документа сначала записывается пустой набор записей по регистратору. Срабатывает проверка на остаток и уходит в отказ. Поможет сменить способ удаления движений.
Способ не универсальный на все случаи жизни, но как концепция хороший.
1:10:00 Не понял пояснения со слов «в чём соль». Автор приводит пример, когда реквизит Организация переименовывается в ОрганизацияОтправитель и далее поясняет, что использование структуры «ДанныеЗаполнения» упростит рефакторинг после переименования, благодаря использованию такого подхода можно будет действовать итеративно. Не понятно как. Если у меня в структуре всё ещё старое название реквизита Организация, мне нужно найти по коду все места где эта структура ДанныеЗаполнения формируется и везде поправить. В чём итеративность и в чём преимущество перед способом Организация = Организация (без использования ДанныеЗаполнения)?
Найти действительно будет нужно, но не обязательно делать это сразу. Вы на первом этапе сможете вставить в обработку заполнения проверку на наличие свойства "Организация" и, при его наличии, заполнить ОрганизацияОтправитель = ДанныеЗаполнения.Организация. Это будет промежуточным решением и обработки продолжат работать корректно, а вы, на этом этапе, измените код только в 1 месте
Одна точка входа
@@user-ww9oi6fm4x корректоно работать не продолжат, тк организацияотправитель заполняться не будет, просто не будет ошибки- поле объекта не обнаружено...с точки зрения бизнеса это возможно будет еще хуже
@@albrehtdurer557 ну как же заполняться не будет, если мы код с заполнением вставили?) в комментарии выше пояснил какие действия нужно сделать одновременно с переименованием
@@user-ww9oi6fm4x без переименования , при заполнении из данных заполнения - не будет работать, т.е. "работы" по поиску и переименованию все равно не избежать, для корректного заполения. Разбивать процедуру рефакторинга, на два шага , как вы предлагаете -"но не обязательно делать это сразу", что значит не обязательно?, Клиенту необходимо , что-бы ОрганизацияОтправитель, заполнялась сразу...
Зачем при создании на сервере делать проверку на пустую ссылку? Только при копировании документа это актуально, но тогда и проверять не на пустую ссылку, а на значение копирования из параметров. Или я ошибаюсь?
Не только при копировании, но и при создании документа, например, на основании. Проверка по ссылке - это наиболее простой и стандартный подход для проверки на новый объект в модуле формы
46:48 избыточный код запроса на поступление какой-то. Зачем делать вручную соединение если проще "ГДЕ Товары.Номенклатура.Тип=" поставить?
спецы не любят точки (скрытые джойны)
ну если следовать логике единообразия, токда все реквизиты надо проверять прогрммно в одном месте, а выставлять проверку на уровне платформы не надо... постаянное переключения между чтением кода, и прокликиванием реквизитов ...как бы не добавляет удобства разработки
Мне тоже так кажется. Но видимо как раз единого места проверки нет. Все равно будет несколько модулей. Поэтому единственный источник правды - свойства реквизитов.
46:48 а зачем вообще соединение с Номенклатурой? Почему просто через точку не написать ГДЕ Товары.Номенклатура.Тип = &Товар ?
Идет отбор сразу по типу номенклатуры перед результирующей таблицей (отберет таблицу номенклатуры перед соединением сразу с типом "товар"), а если в секции где использовать, то отбор будет на результат и потребуется обращение на сервер за параметром типа номенклатуры дополнительно. Также если обращаться через точку в отборе в любом случае будет левое соединение в плане запроса (но отработает как внутреннее), а тут указывается явная инструкция для плана запроса на внутреннее соединение. В конкретном случае может быть и не стоило бы заморачиваться (кроме того что даем явные инструкции построителю плана запросов) со сложной конструкцией, но это хорошая практика, так как в других более сложных случаях простая конструкция в секции где скажется тяжело на выполнении запроса.
Очень сильно смутила передача ссылки на документ в запрос проверки заполнения. Ведь для нового документа она будет пустой и проверка заполнения выполнена не будет. Причем в приложенной базе эта ссылка не используется, а товары в запрос выбираются из объекта документа.
Ссылка используется для ветвления алгоритма. В базе действительно нет примера, т.к. Все упрощено. Пустая ссылка имеет достаточную информацию для маршрутизации (тип)
Насчет вилки будет и обратная ситуация - крутые ребята не видят вилку и проходят мимо потому что не интересно
10
...удобство поддержки, спорное конечно...- Если все одевают штаны, через голову....
Если все с пятого этажа начнут прыгать …
Еще один. Докладчик же объяснил. Это для решений где много регистров и документов. И сотни тысяч, а то и миллионы строк кода. Если такие увидите, то поверьте, что там это удобно
@@LosashExote я такое видел, поверь это не удобно...
@@albrehtdurer557 ладно, я по твоим комментам и ответам поверил уже во все что надо
Конечно круто так код писать, но это где-то в параллельной вселенной, где у тебя неограниченное количество времени и все ждут тебя. В реале, у тебя просто времени не хватит все это написать, а потом ещё и отлаживать/тестировать
Вас верно, это про мультикомандную разработку и ежедневные релизы в большой компании с онлайном >1к пользователей
А что делают остальные 198 человек делают?
Мы не смогли позвать остальных)
Практически всё, что он говорил есть в книгах по 1С и рассказывается на курсах (по программированию: клиент-серверное, УФ, СКД) от 1С и курсы-по-1с.рф. В видео информация подается скомкано, бессистемно.
Ахаха) конечно все уже давно есть и описано в стандартах и книге по проф разработке. Только там примеров мало и читать надо. Видео проще посмотреть
@@yellow_club Проще. Но не это.
автор почему ты в шапочке
Потому что мам говорит, что кепка мне идёт
Абсолютно все неправильно. Почему вы не показываете на примере УТ или УНФ?
Потому что нельзя показывать код типовых
@@yellow_club В том-то и беда
Можно конкретно, что неверно?
@@Gesperid Ну вот пару примеров: Обработка проведения и заполнения. В заполнении в типовых конфигурациях используется что-то вроде делегатов. В проведении используется многоэтапный алгоритм. Сначала подготовка общей структуры параметров. Затем инициализация сначала общей таблицы, затем для каждого регистра. И все это в модуле менеджера. Затем в общем модуле метод записи один на всех. Это если кратко
@@user-rj4hq2vb2n Про проведение. Не понял, где противоречие с докладчиком? Он, в частности, упомянал 1:01:30 функцию ДанныеДляПроведения.
очень странный подход, генерить процедуру на каждое сообщение, а если там 10 табчастей и 10 проверок, это 100 процедур?)))))
Не преувеличивайте. Посмотрите модули механизмов в типовой УТ.
1с код нельзя писать правильно, тут даже нет наследования и обьктов с которыми ты сам можешь работать , модифицировать и переопределять. 1с это 1 большой класс БОГА.
Наследование все ваше считается антипаттерном. Но наследование в 1С есть, ровно как и классы
Любой документ, справочник это есть тебе класс, документы менеджер документов вот тебе класс документов, документ приходная накладная наследует от документа, метод создать, и тд и свойства. Но да ты их не можешь переопределить.
А нех их переопределять, но можешь их дополнить своими методами в модуле менеджера.
220 - 1с-ников на 2000 человек!!!!!!!!!!!!!!!!!!!!!!!!!!! Это капец!!!!!!!!!!!!!!!!!!!!!!! И это не фирма-разоаботчик!!!! Да так не бывает. Я не видел отдела больше 9 человек (1с) примерно на 35 000 работников. На 2000 пользователей 3, ну 5, а скорее всего 2. Но 220!!!!!!!
Скажите мне, что я ослышался.
Ты не ослышался. Нормальный отдел.
Так вроде smlab - это типа it-отдела на 2000 чел для фирмы из 15 тысяч народа.
"SM Lab - ИТ компания в составе группы компаний «Спортмастер», которая строит свою работу на современных принципах управления разработкой и актуальном стеке.
Мы делаем ИТ системы, на которые опирается наш бизнес, благодаря которым он растет и развивается"
У нас около 30 1сников на тысяч 5000 человек. Растет компания проектов на разработку бывает много очень.
@@lickassover9000 ну чего, завидую. Я сейчас один на 50 юзеров, + сисадмин, + поддержка ИТС. А спрашивают как с нормальных, и отчёты нестандартные, и обмены, и премии к зарплате. И сравнивают вот с такими, где 20-200 чел. Что они конфигу под запрос делают, а ты не можешь
Он реально написал "Если Не ЗначениеЗаполнено(Объект.Ссылка)", в 2023-м? Вы че там, подписчиков так троллите, что ли?
Что не так?
Да, мы троллим, проходи мимо
не сложно изучить стандарты. надо просто работать с этими стандартами, а не там-сям...с народным творчеством. за 1 год уже можно хорошо ориентироваться. я в ЕРП заезжал почти с нуля, быстро освоился за 3 месяца, но дальше никак. перекинули на древнее зло :)
Организация мечты, особенно для новичков. Жаль не обучают. А то сначала учишься говнокодить, потому что выбора нет, а потом переучиваешься на нормальное.
Таков путь)
Я не думаю что вообще стоит с нуля учить сразу подобным подходам. Не будет понимания зачем именно так, а на этом уровне как раз нужно именно понимать, зачем ты так все усложняешь. Докладчик мега грамотно защитил свои подходы краткими и лаконичными примерами, я бы так не смог выразить, хоть и придерживаюсь веры в правильность тех же учений.
зарплата это как дети, только наоборот. я говорит детей не люблю, но сам процесс. я получать люблю зарплату, а не считать :)
готового разработчика сразу хотят. а ты его вырасти, лелей как самого способного, а потом требуй. а то хотят получить конфетку среди разрухи и конкуренции.
Улетай селен на луну, улетай!
Эпиграф:
Новые существа пусть покоряют
Просторы Вселенной, а мы на земле пока.
С помощью ИИ расшифруем ДНК, модификация;
Откроем новые грани науки -
Трансформация ;
Создадим существ необычных форм,
New цивилизация,
А на Земле устроим настоящий шторм
Бифуркации!
Триллер будет нешуточный вокруг,
Соревнования ;
Все будут ждать, что случится дальше -
May be игромания,
А мы уже готовы отправить творения
Для созидания,
В далёкий космос рисковать собой
Познавая мироздание...
Там им откроются другие миры, со скрипом
Ибо long расстояния,
Новые планеты и галактики спиральные
Это good супермания,
Всех нас ждет такой невероятный путь,
Покорения науки знания
Который приведет нас к счастливой жизни
В хаосе непонимания.
Спасин Спаситель, Белая Вера вбирает
Всё самое необходимое;
Человек родитель, в БИОС прошивка строго
Люди для роботов Боги;
Если не уверуем в Ваню и отринем Его заветы родимые,
То станет землю безлюдной и в никуда поведут Чат Джи пи Ти 100 дороги...
Спасин
Улетай селен на луну, улетай!
Эпиграф:
Новые существа пусть покоряют
Просторы Вселенной, а мы на земле пока.
С помощью ИИ расшифруем ДНК, модификация;
Откроем новые грани науки -
Трансформация ;
Создадим существ необычных форм,
New цивилизация,
А на Земле устроим настоящий шторм
Бифуркации!
Триллер будет нешуточный вокруг,
Соревнования ;
Все будут ждать, что случится дальше -
May be игромания,
А мы уже готовы отправить творения
Для созидания,
В далёкий космос рисковать собой
Познавая мироздание...
Там им откроются другие миры, со скрипом
Ибо long расстояния,
Новые планеты и галактики спиральные
Это good супермания,
Всех нас ждет такой невероятный путь,
Покорения науки знания
Который приведет нас к счастливой жизни
В хаосе непонимания.
Спасин Спаситель, Белая Вера вбирает
Всё самое необходимое;
Человек родитель, в БИОС прошивка строго
Люди для роботов Боги;
Если не уверуем в Ваню и отринем Его заветы родимые,
То станет землю безлюдной и в никуда поведут Чат Джи пи Ти 100 дороги...
Спасин
Гордиться тем, что вы на простом и таком привычном дне, это такой себе повод.