Наверное от области зависит. Программисты с 20летним стажем не считают ИИ чушью, ибо на кодинг он очень тренирован
Программисты с 20-и летним стажем должны понимать что разработка ПО это всегда компромисс между красивыми/правильными и быстрыми решениями. И то что ИИ анализирует коммиты ничего ему не дает, он просто не понимает почему было такое решение/библиотека выбрано, а не другое, так как нету бизнес контекста на нужный момент времени. В разработке пока никто не научился создавать ТЗ с первого раза без ошибок, и недаром есть всякие POC, MVP - на которых ИИ тоже учиться. Да для типичного решения алгоритмов или создания типичных тестов ИИ хорошо подходит, для остального хорошо создает видимость "профессионала".
Найм в ИТ был нормальным в начале 2000-х. Когда при устройстве на работу, после собеседования тебе давали комп с доступом к проду и давали какие-то "простые" и не очень задания. На должность админа могли попросить например обновить sendmail главного почтового севера, а на должность разработчика поправить какой-то простой баг, сделать пару тройку запросов в базу. И сразу было понятно что знаешь/работал ли с продом и как решаешь задачу, как оцениваешь риски и что будешь делать в случае ошибки. Такой себе livecoding на максималках.
Что раньше, что сейчас инженеры решают задачи исходя из ТЗ. Если вопрос быстродействия не освещен в ТЗ, то критерием выступает субъективное ощущение быстродействия на локальной машине. Да раньше не было фреймворков, но были библиотеки со своей спецификой и особенностями.
array - список реплик для чтения, список endpoint-ов для каких-то запросов, список доступных языков, список доступных валют. Обычно приходиться колхозить что-то типа DATABASE_REPLICA_1, DATABASE_REPLICA_2 и тд. и ваш конфиг типа такого
{
database: {
replicas: $DATABASE_REPLICA_*
}
}
что развернеться в
{
database: {
replicas: [$DATABASE_REPLICA_1, $DATABASE_REPLICA_2]
}
}
object - тут чуть сложнее с примерами, они более редкие, это может быть например конфигурация oauth провайдеров, и будет что-то типа OAUTH_GOOGLE_ID, OAAUTH_GOOGLE_SECRET, OAUTH_APPLE_ID, OAUTH_APPLE_SECRET и тд. и ваш конфиг типа такого
Go отличный язык для своей ниши, но есть нюансы. Если допустить что любой ЯП синтаксис+runtime+toolchain+stdlib имеет константную сложность, то у Go вся сложность перенесена в toolchain, в результате этого получаеться очень простой язык, но очень сложная обвязка вокруг него. Вот как пример https://golangci-lint.run/docs/linters/, 112 литеров это мягко говоря перебор. В Rust например ситуация кардинально противоположная, вся сложность перенесена в компилятор. И как только дело касается soft real time или hard real time, то Go просто не подходит.
Есть определенные области работы которые привлекают злоумышленников. И неудивительно что разработчики которые связанны с финансами представляют ценность для направленых атак, и не важно крипта или работа с банке.
Насчёт кубернетиса вы, возможно, правы, но я не соглашусь, что он как-то усложнил мне жизнь. Мне с kubectl легко и удобно. А по деньгам на наших нагрузках там нет принципиальной разницы, было бы $10 вместо $100 — это всё ещё копейки по сравнению с тем же маркетингом.
Да на моей практике разница на порядок, и если 100$ не так драматично как 10$, то 5000$ уже не так приятно как 500$. И мой посыл был в том что куб не решает никакой вашей проблемы, он просто есть и все.
Насчёт сущностей — я всё ещё считаю, что разделить их было верным решением. У них много непересекающихся данных (у атлетов — анкета, биллинг и всё такое, у тренеров — публичный профиль и условия контракта) и не хотелось бы, чтобы они и там, и там были optional. К тому же, получится, что в коде постоянно фигурирует два разных «юзера» и их очень легко перепутать.
В вашей схеме все хорошо до поры до времени, пока тренер сам не захочет заниматься, или использовать какие-то функции доступные только для атлетов (например какой-то контроль веса или что-то типа такого). Анкеты и профили должны быть как у атлета так и у тренера, ну просто потому что им надо как-то сматчиться между собой и эта информация будет полезна обоим (да профиль у тренера открыт, а у атлета закрыт по умолчанию, но у атлета должна быть возможность открыть свой профиль для других). Про биллинг это вообще странно, у тренера как минимум должна быть возможность вывода заработанных денег, ну и депозита для покупки чего-то (платного продвижения, каких-то дополнительных функций и т.д.). Про optional это что-то из nosql мира, в реляционных бд оперируют связями. Попробуйте придумать схему для реляционный бд для своего приложения и увидите что общего намного больше у этих двух ролей и нет смысла их разделять.
Первая - это то что изначально не выбралась реляционная БД. Тот же постгрес закрыл бы весь спектр задач, хранение данных(транзакции, join, group и прочие), организация очереди(простые очереди можно держать в базе), машина состояний(enum + constraint), pubsub(для внутренних событий), ну и хранение сырых(или структурированных) данных от Stripe(вместо использования для этого ClickHouse).
Вторая - это кубернетес. Он избыточен для вашего приложения, и для всего добра хватило одной машины в DO или хетснере, и деплой бы был не сильно сложнее (выполнение всех нужных команд на сервере напрямую из GitHub actions или кнопками в jenkins). Да и скриптовые языки прям больно по деньгам запускать в кубе.
Третья - разделение на клиентов и тренеров. В базе была бы одна сущность users, где было бы что-то типа role: athlete|trainer|both (both на случай что какой-то тренер сам у кого-то занимается), и одно приложение, которое бы исходя из role скрывало бы ненужные блоки. Почему вместе, да потому что эти две роли выполняют одну общую задачу. Отдельно приложение надо делать например для владельцев фитнес клубов, так как их роль и задачи в системе никак не пересекаются с athlete и trainer.
Если резюмировать это все, то вы сами себе усложнили жизнь. И просто повезло что не втянули кролика или кафку.
Интересно почитать вторую часть про бизнес составляющую.
Ubuntu хороша пока не сломается на обновлении драйверов, такое редко, но бывает. Для первого старта я бы выбирал OpenSUSE, btrfs со снапшотами защитит от любого кривого обновления, так же плюсом будет yast через который можно настроить все что только можно в системе, ну и визуально очень приятно все сделано по умолчанию.
Примерно с такими же соображениями в 70-е годы и был придуман язык структурированных запросов SQL...
SQL - это все таки про работу с данными, а я про логику и что-то типа COM(но мультиплатформенное и не только для десктопы). Просишь ИИ создать новый раздел меню в Photoshop или для любой другой программы который например рисует котиков и получаешь результат. Или кнопку в меню для сайта Хабр для фильтрации коментов.
С развитием ИИ скорее всего поменяется архитектура ПО и подходы к разработке.
Программисты будут развивать ядро ПО, а пользователи уже с помощью ИИ используя какой-то механизм (плагины/DSL) будут расширять возможности этого ПО.
В целом если будет тренд на использование ИИ не программистами то будет рост эффективности работы в разных сферах, люди просто смогут автоматизировать кучу рутины с помощью ИИ.
Программисты с 20-и летним стажем должны понимать что разработка ПО это всегда компромисс между красивыми/правильными и быстрыми решениями. И то что ИИ анализирует коммиты ничего ему не дает, он просто не понимает почему было такое решение/библиотека выбрано, а не другое, так как нету бизнес контекста на нужный момент времени. В разработке пока никто не научился создавать ТЗ с первого раза без ошибок, и недаром есть всякие POC, MVP - на которых ИИ тоже учиться. Да для типичного решения алгоритмов или создания типичных тестов ИИ хорошо подходит, для остального хорошо создает видимость "профессионала".
Найм в ИТ был нормальным в начале 2000-х. Когда при устройстве на работу, после собеседования тебе давали комп с доступом к проду и давали какие-то "простые" и не очень задания. На должность админа могли попросить например обновить sendmail главного почтового севера, а на должность разработчика поправить какой-то простой баг, сделать пару тройку запросов в базу. И сразу было понятно что знаешь/работал ли с продом и как решаешь задачу, как оцениваешь риски и что будешь делать в случае ошибки. Такой себе livecoding на максималках.
Что раньше, что сейчас инженеры решают задачи исходя из ТЗ. Если вопрос быстродействия не освещен в ТЗ, то критерием выступает субъективное ощущение быстродействия на локальной машине. Да раньше не было фреймворков, но были библиотеки со своей спецификой и особенностями.
Скорее отрицательно взлетел.
"Сенсация, ученые изобрели антигравитацию"
Любые государственные образовательные учреждения в России со временем так или иначе превращаются в казарму.
array - список реплик для чтения, список endpoint-ов для каких-то запросов, список доступных языков, список доступных валют. Обычно приходиться колхозить что-то типа
DATABASE_REPLICA_1,DATABASE_REPLICA_2и тд. и ваш конфиг типа такогоobject - тут чуть сложнее с примерами, они более редкие, это может быть например конфигурация oauth провайдеров, и будет что-то типа
OAUTH_GOOGLE_ID,OAAUTH_GOOGLE_SECRET,OAUTH_APPLE_ID,OAUTH_APPLE_SECRETи тд. и ваш конфиг типа такогоКак только встает вопрос про валидацию сложного конфига, то оказывается что кроме JSON c JSON Schema больше ничего и нету.
Да и у этого решения тоже есть проблема, object или array никак не прокинешь из переменных окружения.
Go отличный язык для своей ниши, но есть нюансы. Если допустить что любой ЯП синтаксис+runtime+toolchain+stdlib имеет константную сложность, то у Go вся сложность перенесена в toolchain, в результате этого получаеться очень простой язык, но очень сложная обвязка вокруг него. Вот как пример https://golangci-lint.run/docs/linters/, 112 литеров это мягко говоря перебор. В Rust например ситуация кардинально противоположная, вся сложность перенесена в компилятор.
И как только дело касается soft real time или hard real time, то Go просто не подходит.
Есть определенные области работы которые привлекают злоумышленников. И неудивительно что разработчики которые связанны с финансами представляют ценность для направленых атак, и не важно крипта или работа с банке.
С возрастом я тоже стал зумером :)
Да на моей практике разница на порядок, и если 100$ не так драматично как 10$, то 5000$ уже не так приятно как 500$. И мой посыл был в том что куб не решает никакой вашей проблемы, он просто есть и все.
В вашей схеме все хорошо до поры до времени, пока тренер сам не захочет заниматься, или использовать какие-то функции доступные только для атлетов (например какой-то контроль веса или что-то типа такого). Анкеты и профили должны быть как у атлета так и у тренера, ну просто потому что им надо как-то сматчиться между собой и эта информация будет полезна обоим (да профиль у тренера открыт, а у атлета закрыт по умолчанию, но у атлета должна быть возможность открыть свой профиль для других). Про биллинг это вообще странно, у тренера как минимум должна быть возможность вывода заработанных денег, ну и депозита для покупки чего-то (платного продвижения, каких-то дополнительных функций и т.д.). Про optional это что-то из nosql мира, в реляционных бд оперируют связями. Попробуйте придумать схему для реляционный бд для своего приложения и увидите что общего намного больше у этих двух ролей и нет смысла их разделять.
Я вижу три технических ошибки.
Первая - это то что изначально не выбралась реляционная БД. Тот же постгрес закрыл бы весь спектр задач, хранение данных(транзакции, join, group и прочие), организация очереди(простые очереди можно держать в базе), машина состояний(enum + constraint), pubsub(для внутренних событий), ну и хранение сырых(или структурированных) данных от Stripe(вместо использования для этого ClickHouse).
Вторая - это кубернетес. Он избыточен для вашего приложения, и для всего добра хватило одной машины в DO или хетснере, и деплой бы был не сильно сложнее (выполнение всех нужных команд на сервере напрямую из GitHub actions или кнопками в jenkins). Да и скриптовые языки прям больно по деньгам запускать в кубе.
Третья - разделение на клиентов и тренеров. В базе была бы одна сущность users, где было бы что-то типа role: athlete|trainer|both (both на случай что какой-то тренер сам у кого-то занимается), и одно приложение, которое бы исходя из role скрывало бы ненужные блоки. Почему вместе, да потому что эти две роли выполняют одну общую задачу. Отдельно приложение надо делать например для владельцев фитнес клубов, так как их роль и задачи в системе никак не пересекаются с athlete и trainer.
Если резюмировать это все, то вы сами себе усложнили жизнь. И просто повезло что не втянули кролика или кафку.
Интересно почитать вторую часть про бизнес составляющую.
Торт
Если говорить про документацию, то я бы сказал что самая лучшая документация у Gentoo.
Ubuntu хороша пока не сломается на обновлении драйверов, такое редко, но бывает. Для первого старта я бы выбирал OpenSUSE, btrfs со снапшотами защитит от любого кривого обновления, так же плюсом будет yast через который можно настроить все что только можно в системе, ну и визуально очень приятно все сделано по умолчанию.
SQL - это все таки про работу с данными, а я про логику и что-то типа COM(но мультиплатформенное и не только для десктопы). Просишь ИИ создать новый раздел меню в Photoshop или для любой другой программы который например рисует котиков и получаешь результат. Или кнопку в меню для сайта Хабр для фильтрации коментов.
С развитием ИИ скорее всего поменяется архитектура ПО и подходы к разработке.
Программисты будут развивать ядро ПО, а пользователи уже с помощью ИИ используя какой-то механизм (плагины/DSL) будут расширять возможности этого ПО.
В целом если будет тренд на использование ИИ не программистами то будет рост эффективности работы в разных сферах, люди просто смогут автоматизировать кучу рутины с помощью ИИ.
Вообще-то давно уже существуют и продаются лазерные микрофоны. Так что такая себе новость.
Дизайн на любителя. Похоже на бутылку водки в какой-то странной подставке.
История с совместным самолетом похоже ничему не научила.