Пока - нигде. Но люди оставляют о себе столько информации, что осталось просто это собрать воедино и переходить от "для многих" к "только для тебя". С рекламой так уже почти работает. Вопрос времени, как мне кажется.
Вы пробовали заставить ИИ делать UI?
Конечно. Делает лучше чем я сам бы сделал, но это скорее говорит о моих способностях к построению UI.
Я пытаюсь понять, где мы (условно) сломаемся. Когда произойдет качественный скачок. Что такое должно появиться, чтобы пропала необходимость в разработке ПО, именно как в процессе.
Скажите 5 лет назад, что поиск гугла провалится по посещаемости - покрутят пальцем у виска. Сейчас просто спрашивают "Чат ...". То, что он выдает - надо иногда проверять, хотя бы. Но многим пользователям - заходит.
Опять же, вы думаете в парадигме точного и выверенного расположения элементов. "Пользователь будущего" может ограничится тем, что ему предложит ИИ, с минимальными правками: "Подвинь, собака, кнопку ниже! И сделай ее больше."
Т.к. Супермодель знает все про пользователя, она сразу будет понимать что ему нравится, как удобнее для него расположить элементы и настроить их размер.
Например, балерине надо изящество и красота. Грузчику (если они останутся) надо, чтобы он мог своими пальцами-сардельками попасть в кнопку и не задеть еще пять вокруг.
Как раз я про это и пишу. Что программисты делают приложения "для всех". А условному пользователю нужно лишь 10% от этого "для всех".
Интерфейс пользователю хочется свой. Так как ему "красиво".
Я пытаюсь донести мысль, что мы думаем в парадигме "ИИ будет писать код за нас". Это сродни "Завтра построят новый завод в Самаре и он будет делать неломающиеся телевизоры с ЭЛТ". А на самом деле, уже где-то делают "плазму" и "светодиоды".
Так и здесь. Пока мы сравниваем хорошо ли модель пишет код или плохо, где-то, кто-то делает так, что не будет никакого кода.
Пока мы пишем приложения, удобные максимальному числу пользователей - кто-то думает в сторону "А нафига оно вообще? Пусть пользователь делает себе то, что он сам хочет. Пусть это выглядит ужасно, но ему так нравится".
Возьмите супермодель, себя и Эллочку-людоедку из "Двенадцати стульев".
Отличный пример.
Мы, обобщенные айтишники, "испорчены" образом мышления, что есть некий программный код, который надо понимать. Есть архитектура, есть правила и стандарты...
А теперь представьте, что ничего этого больше нет.
Прибегает домой взбешенная Эллочка, открывает "Супермодель" и пишет ей там: "Я сегодня увидела у этой шмары с патриков, календарик. Она там напоминалки картинками своей блохастой твари отмечает. Хочу такой же календарик, но чтобы были картинки Пусички".
Супермодель знает, что "шмара с патриков" это Катя из Бирюлево. Что "блохастая тварь" - это ее кошка. Что "Пусечка" - это корги Эллочки (фотографиями собачки завалены все ее соцсети). А "календарик"- Супермодель сама делала для Кати.
Модель не знает никакого исходного кода. Он ей просто не нужен. Она знает функционал. И просто создает приложение, без какого либо промежуточного слоя в виде языка программирования. Сразу в бинарнике. Сразу ставит на телефон Эллочке. Ей и только ей. Персонально.
Вот начитается молодёжь таких советов от нейросетей, а потом коноплю свою колють.
Всегда используйте суррогатный первичный ключ Не всегда. Для ссылочных сущностей - оправдано. Таблица курсов валют. Дата, Валюта, Курс. Объясните здесь смысл поля id?
Каждая таблица ОБЯЗАНА иметь created_at и updated_at Не обязана. Должна быть целесообразность. Не надо категорических суждений.
Та же таблица курсов валют. Ее можно хоть всю передавать, хоть загрузить из интернетов.
Показания промышленных датчиков или (вписать любое, что льется в базу миллионами строк в час и не предполагается к синхронизации в разных базах)
Чеки в магазине. Где есть шапка чека и товарное содержимое чека (намертво привязанное к шапке). Поля в шапке оправданы, а в строках они зачем?
Используйте TEXT вместо VARCHAR(n) Тут вопрос скорее понимания структуры БД. Открыл поля таблицы и примерно понятны ограничения, если указан VARCHAR. Если TEXT, то возникает ощущение, что можно туда запихать гигабайтный XML.
Используйте BIGINT / BIGSERIAL для ID, а не INT Я бы посоветовал: используйте uuid7 для id, если база не требует экстремальной производительности. Позволяет избежать огромного числа проблем при синхронизации между разными базами или замены id (а такое тоже случается).
ВСЕГДА определяйте явные внешние ключи Тезис спорный. Зависит от профиля нагрузки и от логики приложения. Достаточно актуальная проблема для мобильных устройств, когда из леса вынырнул пользователь с приложением 3-х годичной давности. И вам надо его протащить через 50 версий обновления. С внешними ключами это еще та морока, не забыть словить какой нибудь каскадный update или delete. Нет, оно решаемо, но без ключей сильно проще.
Используйте CHECK-ограничения для валидации данных Тезис достаточно спорный. Зависит от приложения. Иногда, лучше оставить логику проверки самому приложению.
"Ограничения в БД — это последний рубеж обороны, и они работают всегда." И тут программисты приложения, которые ничего не знали про эти ограничения в БД (т.к. БД занимается отдельный человек) хватанули полную панамку этих ограничений, выкатив новую версию. На их базе все же работало!
Создавайте индексы для каждого WHERE, JOIN и ORDER BY Да щас! Нейросеть, которая это писала явно не работала с большими ERP-системами, где количество комбинаций полей в WHERE, JOIN и ORDER BY - огромное.
Следуйте этому совету и у вас 90% базы будут занимать индексы. А время записи в любую таблицу будет на 90% состоять из обновления страниц индекса.
Используйте EXPLAIN ANALYZE перед деплоем запросов Программисты каждый запрос будут прогонять через EXPLAIN ANALYZE и тратить время на анализ. И у каждого программиста есть доступ к рабочей базе, где он может проверить как запрос действительно отработает (а не база в 5 мегабайт для разработки). А еще единороги едят радугу.
Два слова: Нагрузочное тестирование.
Используйте пулинг соединений (PgBouncer) Зависит от профиля нагрузки. Для web приложений, где время жизни транзакции\запроса (в итоге соединения ПО-БД) небольшое - ОК.
Если это кровавый энтерпрайз, где транзакция может состоять из сотен запросов и занимать несколько секунд, то с увеличением числа пользователей, начнет расти кол-во соединений на PgBouncer.
А как вы знаете (надеюсь) он работает в одно ядро. И в районе 150-200 соединений, ваше приложение начнет получать ошибки соединения с БД т.к. ядро будет загружено на 100%. Даже самые оптимистичные его бенчмарки дают 200-300 соединения с БД. Но я проверял - 150-200 и все, кранты.
Да, можно поднять несколько процессов PgBouncer, но там поднимается процесс координатор и (скорее всего) откажет именно он (не стал проверять).
Всегда используйте транзакции для многошаговых операций Этому учат на второй странице любой книги по БД. Если разработчик это не понимает, то лучше вообще к БД не подходить.
Я лично ожидаю в ближайшее время взрыв мини-продуктов от одиночек и микро-коллективов — приложений, которые раньше никто не делал, потому что выигрыш не стоил затрат.
Я уже год+ это жду. Но пока не видно. Как только такие приложения начнут массово появляться, то можно начинать опасаться ИИ.
Причем, опасаться как программистам, так и (внезапно) вайбкодерам. Это будет означать, что теперь "программирование" доступно на естественном языке обычным людям (без "тайных знаний" как правильно писать промпты).
Я выше писал, что по тихому замяли. "Вот ответ на ваши обращения, давайте сядем почитаем и составим список того, что надо собрать. А по нашим операциям мы все знаем, сами с ними разберемся".
Комиссии не было, если и была, то я ее не заметил. Но там прям в тексте перевода было написано, что это вывод денег из-за блокировки по 115-ФЗ. Возможно, при таком переводе не берут комиссию.
В приложении посмотреть не получается. Операции до снятия блокировки не видны =(
И, кстати, про игры. Рискую сейчас быть измазанным коричневым от профессиональных геймдевелоперов. Но все же знают трюк, что главный цикл игры загоняется в try catch и если кадр упал, то фиг с ним - следующий отрисуется как надо?
Если в игре, вместо куста рябины появился боярышник, а вон та мохнатая бытовка, возле дома - это, оказывается, собачья будка... То всегда можно объявить, что так и задумывалось.
Но если вы ошибётесь на 10 копеек в зарплатой ведомости, то работяги, с завода, вас морально (а может и физически) затащат в мохнатую бытовку и бросят в куст боярышника, после.
Именно поэтому, я настороженно отношусь к идее бездумного вайбкодинга в реальных "промышленных" приложениях (в настоящее время).
Вы же стажёра сначала попросите рассказать как он хочет решать проблем му, и если ок - то уже пусть решает. Или вы не глядя его код принимаете?
Конечно. Тут отличие в том, что когда стажеру говоришь "вот эту красную кнопку сделай зеленой", то он не полезет в обмен данными с платёжным терминалом (хотя разные уникумы попадаются).
А почему вы не попросили помощника написать е2е тестов?
Сам пожалел, что не попросил. Кстати, спасибо за подсказку. Верну свое единственное ручное изменение и попробую проверить, найдет ли он ошибку самописными тестами.
На второй тезис попробую ответить так: "скорость и эффективные менеджеры". Теперь подробнее:
Скорость. От паяльников и перфокарт до условного бейсика шли, практически, одни и те же люди. Шли очень плавно. Когда появлялись "чистые программисты", то на старых местах еще работали "перфокаторщики", которые эволюционировали в программистов.
И тут на сцену выходят "эффективные менеджеры": "Выгоним 30% самых неопытных сотрудников и оставим только сеньёров+ИИ", премия и бонус, за скоращение издержек. А куда податься выпертому джуну? Где опыта набираться?
и не знают, как устроен процессор
А это просто не пересекающиеся множества. Те кто не знают - вполне успешно пишут одни приложения (или их модули). Те, кто знают - другие. Я в работе сталкиваюсь и с теми и с другими. Первые не лучше вторых, а вторые первых. Это разные задачи. Только вот тех, кто понимает, найти сложнее (и они дороже, как правило). Возможно, появятся третьи - чистые вайберы. Но тогда они оттянут значительную часть из первой и второй группы.
Пока - нигде. Но люди оставляют о себе столько информации, что осталось просто это собрать воедино и переходить от "для многих" к "только для тебя". С рекламой так уже почти работает. Вопрос времени, как мне кажется.
Конечно. Делает лучше чем я сам бы сделал, но это скорее говорит о моих способностях к построению UI.
Я пытаюсь понять, где мы (условно) сломаемся. Когда произойдет качественный скачок. Что такое должно появиться, чтобы пропала необходимость в разработке ПО, именно как в процессе.
Скажите 5 лет назад, что поиск гугла провалится по посещаемости - покрутят пальцем у виска. Сейчас просто спрашивают "Чат ...". То, что он выдает - надо иногда проверять, хотя бы. Но многим пользователям - заходит.
Ни одного.
Опять же, вы думаете в парадигме точного и выверенного расположения элементов. "Пользователь будущего" может ограничится тем, что ему предложит ИИ, с минимальными правками: "Подвинь, собака, кнопку ниже! И сделай ее больше."
Т.к. Супермодель знает все про пользователя, она сразу будет понимать что ему нравится, как удобнее для него расположить элементы и настроить их размер.
Например, балерине надо изящество и красота. Грузчику (если они останутся) надо, чтобы он мог своими пальцами-сардельками попасть в кнопку и не задеть еще пять вокруг.
Как раз я про это и пишу. Что программисты делают приложения "для всех". А условному пользователю нужно лишь 10% от этого "для всех".
Интерфейс пользователю хочется свой. Так как ему "красиво".
Я пытаюсь донести мысль, что мы думаем в парадигме "ИИ будет писать код за нас". Это сродни "Завтра построят новый завод в Самаре и он будет делать неломающиеся телевизоры с ЭЛТ". А на самом деле, уже где-то делают "плазму" и "светодиоды".
Так и здесь. Пока мы сравниваем хорошо ли модель пишет код или плохо, где-то, кто-то делает так, что не будет никакого кода.
Пока мы пишем приложения, удобные максимальному числу пользователей - кто-то думает в сторону "А нафига оно вообще? Пусть пользователь делает себе то, что он сам хочет. Пусть это выглядит ужасно, но ему так нравится".
Отличный пример.
Мы, обобщенные айтишники, "испорчены" образом мышления, что есть некий программный код, который надо понимать. Есть архитектура, есть правила и стандарты...
А теперь представьте, что ничего этого больше нет.
Прибегает домой взбешенная Эллочка, открывает "Супермодель" и пишет ей там:
"Я сегодня увидела у этой шмары с патриков, календарик. Она там напоминалки картинками своей блохастой твари отмечает. Хочу такой же календарик, но чтобы были картинки Пусички".
Супермодель знает, что "шмара с патриков" это Катя из Бирюлево. Что "блохастая тварь" - это ее кошка. Что "Пусечка" - это корги Эллочки (фотографиями собачки завалены все ее соцсети).
А "календарик"- Супермодель сама делала для Кати.
Модель не знает никакого исходного кода. Он ей просто не нужен. Она знает функционал. И просто создает приложение, без какого либо промежуточного слоя в виде языка программирования. Сразу в бинарнике. Сразу ставит на телефон Эллочке. Ей и только ей. Персонально.
Вот начитается молодёжь таких советов от нейросетей, а потом коноплю свою колють.
Всегда используйте суррогатный первичный ключ
Не всегда. Для ссылочных сущностей - оправдано.
Таблица курсов валют. Дата, Валюта, Курс.
Объясните здесь смысл поля id?
Каждая таблица ОБЯЗАНА иметь created_at и updated_at
Не обязана. Должна быть целесообразность. Не надо категорических суждений.
Та же таблица курсов валют. Ее можно хоть всю передавать, хоть загрузить из интернетов.
Показания промышленных датчиков или (вписать любое, что льется в базу миллионами строк в час и не предполагается к синхронизации в разных базах)
Чеки в магазине. Где есть шапка чека и товарное содержимое чека (намертво привязанное к шапке). Поля в шапке оправданы, а в строках они зачем?
Используйте TEXT вместо VARCHAR(n)
Тут вопрос скорее понимания структуры БД.
Открыл поля таблицы и примерно понятны ограничения, если указан VARCHAR.
Если TEXT, то возникает ощущение, что можно туда запихать гигабайтный XML.
Используйте BIGINT / BIGSERIAL для ID, а не INT
Я бы посоветовал: используйте uuid7 для id, если база не требует экстремальной производительности.
Позволяет избежать огромного числа проблем при синхронизации между разными базами или замены id (а такое тоже случается).
ВСЕГДА определяйте явные внешние ключи
Тезис спорный. Зависит от профиля нагрузки и от логики приложения.
Достаточно актуальная проблема для мобильных устройств, когда из леса вынырнул пользователь с приложением 3-х годичной давности. И вам надо его протащить через 50 версий обновления.
С внешними ключами это еще та морока, не забыть словить какой нибудь каскадный update или delete. Нет, оно решаемо, но без ключей сильно проще.
Используйте CHECK-ограничения для валидации данных
Тезис достаточно спорный. Зависит от приложения. Иногда, лучше оставить логику проверки самому приложению.
"Ограничения в БД — это последний рубеж обороны, и они работают всегда."
И тут программисты приложения, которые ничего не знали про эти ограничения в БД (т.к. БД занимается отдельный человек) хватанули полную панамку этих ограничений, выкатив новую версию.
На их базе все же работало!
Создавайте индексы для каждого WHERE, JOIN и ORDER BY
Да щас!
Нейросеть, которая это писала явно не работала с большими ERP-системами, где количество комбинаций полей в WHERE, JOIN и ORDER BY - огромное.
Следуйте этому совету и у вас 90% базы будут занимать индексы. А время записи в любую таблицу будет на 90% состоять из обновления страниц индекса.
Используйте EXPLAIN ANALYZE перед деплоем запросов
Программисты каждый запрос будут прогонять через EXPLAIN ANALYZE и тратить время на анализ.
И у каждого программиста есть доступ к рабочей базе, где он может проверить как запрос действительно отработает (а не база в 5 мегабайт для разработки).
А еще единороги едят радугу.
Два слова: Нагрузочное тестирование.
Используйте пулинг соединений (PgBouncer)
Зависит от профиля нагрузки. Для web приложений, где время жизни транзакции\запроса (в итоге соединения ПО-БД) небольшое - ОК.
Если это кровавый энтерпрайз, где транзакция может состоять из сотен запросов и занимать несколько секунд, то с увеличением числа пользователей, начнет расти кол-во соединений на PgBouncer.
А как вы знаете (надеюсь) он работает в одно ядро. И в районе 150-200 соединений, ваше приложение начнет получать ошибки соединения с БД т.к. ядро будет загружено на 100%.
Даже самые оптимистичные его бенчмарки дают 200-300 соединения с БД. Но я проверял - 150-200 и все, кранты.
Да, можно поднять несколько процессов PgBouncer, но там поднимается процесс координатор и (скорее всего) откажет именно он (не стал проверять).
Всегда используйте транзакции для многошаговых операций
Этому учат на второй странице любой книги по БД.
Если разработчик это не понимает, то лучше вообще к БД не подходить.
Я уже год+ это жду. Но пока не видно. Как только такие приложения начнут массово появляться, то можно начинать опасаться ИИ.
Причем, опасаться как программистам, так и (внезапно) вайбкодерам. Это будет означать, что теперь "программирование" доступно на естественном языке обычным людям (без "тайных знаний" как правильно писать промпты).
Я выше писал, что по тихому замяли. "Вот ответ на ваши обращения, давайте сядем почитаем и составим список того, что надо собрать. А по нашим операциям мы все знаем, сами с ними разберемся".
Пишем Гугел на Андроиде
Как тебе такое, Ларри Пейдж?!!!
Здравствуйте
Я подавал тут
По выписке - нет комиссии.
В банке распечатывают.
Похоже у них как-то приложение не так работает. После разблокировки не показывает старые операции.
Запрошу выписку, там наверное будет.
Автор, сделали ли вы верный вывод из этой истории: брать оплату у клиентов ТОЛЬКО НАЛИЧНЫМИ ?
Я, к сожалению, не беру. Я только отдаю :(
Но теперь стараюсь с переводами связываться как можно меньше.
Комиссии не было, если и была, то я ее не заметил. Но там прям в тексте перевода было написано, что это вывод денег из-за блокировки по 115-ФЗ. Возможно, при таком переводе не берут комиссию.
В приложении посмотреть не получается. Операции до снятия блокировки не видны =(
Я после этого вообще зарекся переводить суммы больше 10 тыс. Физ.лицам.
Только наличным.
Особенно стрёмно с зарплатной картой. Заблокируют и что делать?
Замяли по тихому. А было бы интересно.
См. UPD.
И, кстати, про игры. Рискую сейчас быть измазанным коричневым от профессиональных геймдевелоперов. Но все же знают трюк, что главный цикл игры загоняется в try catch и если кадр упал, то фиг с ним - следующий отрисуется как надо?
Если в игре, вместо куста рябины появился боярышник, а вон та мохнатая бытовка, возле дома - это, оказывается, собачья будка... То всегда можно объявить, что так и задумывалось.
Но если вы ошибётесь на 10 копеек в зарплатой ведомости, то работяги, с завода, вас морально (а может и физически) затащат в мохнатую бытовку и бросят в куст боярышника, после.
Именно поэтому, я настороженно отношусь к идее бездумного вайбкодинга в реальных "промышленных" приложениях (в настоящее время).
Конечно. Тут отличие в том, что когда стажеру говоришь "вот эту красную кнопку сделай зеленой", то он не полезет в обмен данными с платёжным терминалом (хотя разные уникумы попадаются).
А вот открываем ленту хабра и там такая новость
https://habr.com/ru/news/977174/
Готов поспорить, что у автора, за плечами, лет 10 опыта разработки игр. Но общий фон создается такой, что "Началось! Теперь и игры можно!".
Пока писал комент, возникла идея. На первом курсе написал простейшую игру с лабиринтом на Паскале. Ну что "вайбигратор" - попробуем.
Сам пожалел, что не попросил. Кстати, спасибо за подсказку. Верну свое единственное ручное изменение и попробую проверить, найдет ли он ошибку самописными тестами.
На второй тезис попробую ответить так: "скорость и эффективные менеджеры". Теперь подробнее:
Скорость. От паяльников и перфокарт до условного бейсика шли, практически, одни и те же люди. Шли очень плавно. Когда появлялись "чистые программисты", то на старых местах еще работали "перфокаторщики", которые эволюционировали в программистов.
И тут на сцену выходят "эффективные менеджеры": "Выгоним 30% самых неопытных сотрудников и оставим только сеньёров+ИИ", премия и бонус, за скоращение издержек.
А куда податься выпертому джуну? Где опыта набираться?
А это просто не пересекающиеся множества. Те кто не знают - вполне успешно пишут одни приложения (или их модули). Те, кто знают - другие. Я в работе сталкиваюсь и с теми и с другими.
Первые не лучше вторых, а вторые первых. Это разные задачи. Только вот тех, кто понимает, найти сложнее (и они дороже, как правило).
Возможно, появятся третьи - чистые вайберы. Но тогда они оттянут значительную часть из первой и второй группы.
Посмотрим. Будущее не угадать. Я про "сейчас".