Изучение ИИ чатов в реальной работе продолжается.

Буквально вчера поставил задачу:

Приложение рушится, если 3d окно открепляется от панели в плавающее окно. Ошибка в использовании не существующей памяти. Почему так и что делать?

Это не промт. Промт содержал детальное описание проблемы с кодом и несколько сообщений.

CharGPT в целом дал правильное напутствие. Проблема в пересоздание GL контекста для GLWpfControl. Нужно освободить ресурсы и снова запустить, так как при откреплении меняется родительский контрол и контекст меняется.
Ну вот же. Давай код, верно же отвечаешь. Но не спешим радоваться…

С чего то взял, что есть метод Stop. Видимо он решил, что если при инициализации контрола используется метод Start, то видимо есть и стоп. А вот хер вам. Нет такого.
Я ему конечно же об этом сказал. И гпт запустил более длительную обработку вопроса. Думал думал. И выдал опять фигню.

В итоге, я прикинул к носу и решил, что если мы хотим освободить ресурсы, значит скорее всего этот контрол реализует IDisposable. И у него будет метод Dispose. Так и вышло. Все заработало.
Если бы я на веру брал бы код от ИИ ничего бы не получилось. Надо помнить, что это всего лишь подбор подходящих по контексту слов.

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

Так что не боимся, работы мы не лишимся. На наш век хватит👍

Очень жалко выкидывать код, когда вбухал в него кучу времени.
Сидишь, пыхтишь несколько дней, а потом выясняется: «ну всё, надо откатить назад» или вообще всё переделать. И заранее не всегда угадаешь.

Первый раз это прям больно: злость, торг, отрицание, вся эта классика. А потом с опытом начинаешь воспринимать проще — ну рабочий момент, бывает.

Вот прямо сегодня на проекте поймал такой кейс:
Есть таблица, данные грузятся по 500 записей пачкой (lazy loading, стандартная практика). В библиотеке для отображения данных сразу шли фильтры, но они работают только по тем данным, которые уже подгрузились. То есть — фильтруешь либо первые 500, либо те, что подскроллил. Короче, неудобно.

Я заморочился: сделал свои фильтры, чтобы ходили напрямую в БД. Красота, работает! Но заказчик захотел «все записи сразу, без скролла». А это, на минуточку, полмиллиона строк 😳

Для теста нагенерил 100к и попробовал. Загрузка — минута. Мои фильтры, понятное дело, тоже начинают тормозить, потому что запрос уже идёт по всей базе.
Ради интереса вернулся к стандартным фильтрам — и оказалось, что они работают быстрее. Похоже, там есть кэширование применённых фильтров. На 100к они тоже думают секунд 10, но это всё равно лучше, чем минута.

Теперь думаю, откатываться ли назад или оставить свой вариант на всякий. В любом случае всё равно надо дать заказчику попробовать и пусть сам решает. А мой код… полежит в сторонке, вдруг ещё пригодится🙃
Было?

Одна из моих сильных сторон - делать проекты на полном альтруизме.

Мы сейчас проходим акселератор по одному из моих стартапов. И куратор задал вопрос:
«А как вы поддерживаете проект? Как деньги зарабатываете?».
Мы ответили, что никак. Проект бесплатный. Зарабатывать планируем на услугах вокруг этого приложения. Доп модули, обучение и т.д.
После этой фразы, нам сказали, чтобы мы не вздумали на финальной сессии перед инвесторами такое ляпнуть😅

Но во всем этом есть одна проблема. Мой продукт не может быть платным по своей сути. Он и так аналог других бесплатных приложений. И если делать его платным, то его можно сразу и похоронить.

👨‍💻Делаю я его в свободное время и чаще всего по вдохновению уже второй год. И только сейчас наконец-то у людей начал появляться интерес. Пошли заявки на использование, компании интересуются. Вот в акселераторе что-то получается. Чуть позже напишу по результатам. Очень надеюсь, что из этого что-то выйдет. Вперед к успеху!

Провел очередной эксперимент с ИИ чатом.

Мне нужен был сервис, которого еще не было в проекте. Сделал интерфейс, расписал какие методы у него должны быть, подготовил классы. И попытался сделать сервис ПОЛНОСТЬЮ вайбкоддингом. Все же так верещат, что это прям магия. Расписал промт, описал задачу максимально подробно. Код шустро появился на экране и я добавил его к себе в проект. Начал тестить. И… не работает🤨

Начал разбираться. Алгоритм норм, вроде все как надо. Но посмотрев внимательно, нашел несколько багов. Тут поправил, там поправил. Запустил. Стало лучше, но не работает. В итоге задолбался дебажить и погнал писать сам. Решил придерживаться того же подхода, но с изменениями. В итоге все получилось. Сделал быстро и как мне надо. Да, как я хорош😎

ИИ делает норм небольшие фрагменты. Что-то большое делает с косяками. И честно говоря, с вайбкодингом программирование еще больше превращается в дебаг. Словно ты в легаси бесконечно копаешься. А весь прикол делать нулевые сервисы - это свобода. Пишешь, как хочешь. А когда ИИ сгенерил код, ты опять погружаешься в дебри изучения логики лапши. Что может сильно бесить.
Еще раз убедился, что уметь читать код и понимать его смысл нужно в любом случае. А с ИИ этот навык становится еще более важным.

Fun fact.
Вы вообще помните, как 3 года назад пророчили, что программисты станут не нужны в течение 5 лет?
Кажется я уже это слышал. Про бухгалтеров. Лет 20 назад😄

В последнее время прям достали все айтишные блогеры.
Темы у всех одни и те же. Я для себя выделил топ-3:
1. ИИ
2. Джуны
3. Тупые HR

Про первое - ладно. Хайп, куда ж без него. Думаю, через год-два уляжется. Ситуация очень напоминает «пузырь доткомов» в конце прошлого века. Тогда инвесторы вливали деньги во всё подряд, лишь бы у компании был сайт. Что именно продаёшь — не важно. Главное, что ты в интернете. Итог - куча банкротств и резкое похмелье. Знакомо, да?

Тема номер два. Джуны.🥱
Сколько можно… Эти проблемы обсосали уже сто раз. Да, джунам тяжело. Так было всегда. Просто сейчас из-за разрыва в зарплатах сюда ломятся все подряд, даже те, кто «а чё, прикольно, попробую». Вот и имеем перегрев.

Ну и третья. HR.
Раньше они занимались ровно своим делом: отбор по общим характеристикам, оформление документов, ввод в курс дела. Сейчас им навесили ещё и мини-техсобесы. Всё из-за темы номер 2 - слишком много случайных людей на входе. Вот и выкручиваются. Технорям это, конечно, не нравится. Но что делать?😡

Я сам пока взял паузу в съёмках. Поднадоело. Сейчас у меня завал по проектам. Потому что бабки делаю именно на кодинге. Плюс дополнительно консультирую и обучаю. Пока индивидуально - у меня занимается 2 человека. Может, возьму ещё парочку, но много не потяну. Поэтому редко афиширую. Кому надо - пишите.

Планы на контент есть. Думаю вернуться к съёмкам, хочется чего-то по-настоящему интересного. Один из стабильных вариантов - новый mock-собес. Нужен мидл C#, который готов сниматься и умеет говорить на камеру. Так что если узнал себя - отзовись👋

А вы тоже устали от одинакового IT-контента?

Продолжение истории про загрузку данных в таблицу.

На проекте есть большая таблица с данными. По мере Postrgress она среднего размера (до 500к записей), но ее нужно подгрузить на фронт (у нас сейчас WPF). И конечно же все сразу загрузить нельзя. Иначе все встанет. И это даже не связано с конкретное WPF таблицами. На React тоже не стоит это дело выводить, так как на отрисовку фронта требуется время и память. Так что чем больше визуальных компонентов, тем тяжелее будет клиенту.

Обычно это решается порциональной загрузкой. Загружаем по 500 штук и добавляем событие на скролл вниз. Если дошли до конца порции, подгружаем еще. Но заказчик встал в позу:
"Мы работаем в другом приложении. Там все сразу выводится, как в экселе. Хотим так же и тут. Нужно чтобы скролл бар позволял перемещаться по всей таблице".
Да бля...

Сейчас в таблице уже есть свой тип данных для отображения одной строки. Он массивный и нагруженный по функциям. Уже очень много зависимостей от него в других местах приложения. Плюс надо помнить, что эта визуальная таблица отображает данные из 2 совершенно разделенных таблиц из БД. Что вызывает определенные трудности.

Теперь нужно сделать совершенно другой. Общий тип. Пообщались с коллегой, решили делать общий запрос через представление (SQL View). Используем оператор UNION ALL и сливаем 2 таблицы в одну.
Затем добавляем параметр OFFSET, чтобы скролл позволял перемещаться по таблице так, словно она вся уже загружена. И скролл бар делаем отдельно и добавляем его к DataGrid. А родной скрываем. И вуаля.

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

Пока пишу этот пост, пришла мысль сделать отслеживание прокрутки и кастомного скролла. Крутим колесо, скролл движется за ним. Заранее подружаем с запасом и как только доходим до 70% от подруженных данных, подтягиваем еще.
Единственное не придумал, как подниматься наверх.
Как-то так🙃

Короче. Все уже в курсе, что я пишу свою Lowcode платформу NVP-studio. На ней можно писать программы на нодах. И внутри сами ноды создаются на C# и Python.

По мере роста скрипта раздувается большая мешанина из "удона", которую трудно поддерживать. И возникла идея сделать инструмент, который проанализирует все блоки и создать один Python код на их основе. Что позволит быстро накидывать программу блоками, а потом переводить его в лаконичный и удобный для расширения код.
Как вам идея? Я чет прям загорелся и мне дико нравится эта мысль. Хочу назвать эту фичу "Сделай красиво"🙃

P.S. На картинке реальный скрипт по созданию моста в моей приложуне. Чуть позже будет статья с разбором этого проекта!

Делюсь небольшим инсайтом по моему проекту NVP.

Вчера вечером копался в коде и нашел интересную штуку.
При создании любого 3D-объекта во время выполнения скрипта происходило обновление всей сцены.
Оказалось, что при вызове методов создания объектов выставлялся флаг NeedUpdate = true,
а у меня при его изменении сразу срабатывал принудительный апдейт сцены.

А теперь внимание: сама сцена обновляется путем очищения и последовательного вызова функции Render у всех созданных объектов.
(Если что, это не костыль, так реально делается).

В итоге при пошаговом создании объектов скрипт каждый раз заново перерендеривал всё, что уже есть.
Получался эффект "постепенного возведения" - не баг, а фича😅
Но это сильно тормозило выполнение. А скорость для моего движка критически важна.

Переделал логику: теперь обновление происходит только в конце выполнения скрипта, а не после каждого вызова.
Результат - всё стало работать заметно быстрее.

Короче, неделя после использования Cursor.
Честно скажу, классно, что он умеет работать со всеми файлами проекта. НО!
Недавно я полностью обновил свою фичу с помощью ИИ, которая работала не так хорошо, как хотелось бы. И заметил одну странность. Местами стало работать хуже, чем было. И как на зло закончился пробный период использования Cursor. Еще не решил, что купить из ИИ агентов. ChatGTP или Cursor. Поэтому не тороплюсь.

В итоге полез в код. Очень красиво оформлено, комментарии и все такое. Читаю глубже и вижу, что в итоге он просто забил на важные вещи, о которых я просил😡. Некоторые возможности в коде вообще словно не заметил. Создал лишние абстракции и переменные. В итоге сижу разбираю в ручную... бесит... Словно в легаси копаюсь.

Недавно видел новость, что по результатам испытаний ИИ чаты только растянули разработку.
Вот ссылка на статью и разбор исследования.

Еще раз убеждаюсь, что на наш век работы хватит. ИИ - это генератор подходящих по смыслу слов, а не инженер. Он не умеет изобретать.
Что думаете?

Последние полгода активно разрабатываю приложение для автоматического формирования чертежей в программе Autodesk Revit. Пишу на C#.

Самое сложное - анализ направления расстановки размеров и выносок. Сейчас наконец-то стало более менее выглядеть. Не то, что было в начале. Алгоритм стал умней.

Рассказал максимально сжато. Под капотом скрыто много всего интересного. Дофига логики, проверок и доп возможностей. Например, он умеет определять путь между 2 элементами внутри системы.
Хвастаюсь🙃

Если хотите себе такой же или научиться создавать подобное, пишите @ruslan_sh_dev