Снова про ChatGPT
В последнее время так получилось что я работаю с фронтендом и много пишу на React/TypeScript. До начачала использования ChatGPT я просто полагался на свой большой опыт в бекенде, некоторые интуитивные штуки и гуглеж. Но сейчас ИИ стал прям постоянным бадди который четко отвечает на вопросы, помогает писать некоторые куски кода, скидывает мне примеры, описывает плюсы и минусы разных подходов. По моим ощущениям продуктивность изучения технологии, эффективность реально ощутимо выросли. Изначально было и про выросшее качество кода но тут видел в тви ссылку на исследование что ИИ приводит к понижению качества кода, так что тут еще посмотрим :) субъективно - растет, объективно - не знаю.
Это вот то самое пресловутое "рост производительности труда". Как писали умные люди - к безработице это не приведет, но приведет к необходимости переучиваться, еще большему количеству новых рабочих мест, и росту среднего благосостояния.
Наскринил рандомных мест из диалога для примера (появятся в комментариях к посту). Это по сути я в новой для себя технологии занимаюсь архитектурными делами + одновременно изучаю эту самую технологию и докапываюсь до всяких непонятных мне деталей. А этих непонятных деталей в каждой новой технологии всегда полно.
Так что если вам не хватает ментора - за 20 долларов в месяц его легко сейчас найти :)
Скоро еще сделаю пост с различными хаками которые помогают работать с ИИ эффективнее.
В последнее время так получилось что я работаю с фронтендом и много пишу на React/TypeScript. До начачала использования ChatGPT я просто полагался на свой большой опыт в бекенде, некоторые интуитивные штуки и гуглеж. Но сейчас ИИ стал прям постоянным бадди который четко отвечает на вопросы, помогает писать некоторые куски кода, скидывает мне примеры, описывает плюсы и минусы разных подходов. По моим ощущениям продуктивность изучения технологии, эффективность реально ощутимо выросли. Изначально было и про выросшее качество кода но тут видел в тви ссылку на исследование что ИИ приводит к понижению качества кода, так что тут еще посмотрим :) субъективно - растет, объективно - не знаю.
Это вот то самое пресловутое "рост производительности труда". Как писали умные люди - к безработице это не приведет, но приведет к необходимости переучиваться, еще большему количеству новых рабочих мест, и росту среднего благосостояния.
Наскринил рандомных мест из диалога для примера (появятся в комментариях к посту). Это по сути я в новой для себя технологии занимаюсь архитектурными делами + одновременно изучаю эту самую технологию и докапываюсь до всяких непонятных мне деталей. А этих непонятных деталей в каждой новой технологии всегда полно.
Так что если вам не хватает ментора - за 20 долларов в месяц его легко сейчас найти :)
Скоро еще сделаю пост с различными хаками которые помогают работать с ИИ эффективнее.
Сидел сейчас рефакторил очередной сложный кусок и интересная мысль пришла в голову:
Написание чистого кода требует чистой головы. А чтоб ваш разум был чист в процессе работы - он не должен быть забит знаниями о том, как будут работать те или иные вызовы на 4 уровнях абстракции ниже или выше. Чем большим количеством текущего контекста забита голова, тем меньше места остается на непосредственную текущую задачу.
Я люблю писать красивый и чистый код, и наверное поэтому я постоянно пытаюсь все упростить до максимального состояния :) и именно доведение каждого слоя приложения до самостоятельного независимого состояния в итоге и приводит к тому что очень легко становится с ним разбираться и не нужно "знание" о том как работает другой уровень, чтоб внести изменения на текущем.
Написание чистого кода требует чистой головы. А чтоб ваш разум был чист в процессе работы - он не должен быть забит знаниями о том, как будут работать те или иные вызовы на 4 уровнях абстракции ниже или выше. Чем большим количеством текущего контекста забита голова, тем меньше места остается на непосредственную текущую задачу.
Я люблю писать красивый и чистый код, и наверное поэтому я постоянно пытаюсь все упростить до максимального состояния :) и именно доведение каждого слоя приложения до самостоятельного независимого состояния в итоге и приводит к тому что очень легко становится с ним разбираться и не нужно "знание" о том как работает другой уровень, чтоб внести изменения на текущем.
Завтра залейтайте к нам на стрим! :) мы немного изменили планируемую тему с рекрутинговой на ИИшную но надеюсь это будет более интересно :)
Forwarded from ROSLOVETS: Product, Startup, IT
Как использовать GPT-4
😐 Создание контента: 📝 От создания блогов до составления привлекательных подписей в социальных сетях, GPT-4 кардинально меняет подход к созданию контента.
😐 Персонализированное образование: 🎓 ИИ-репетиторы на базе GPT-4 могут предоставлять индивидуализированные пути обучения, определяя сильные и слабые стороны каждого ученика. Это позволяет предлагать настроенные уроки, упражнения и обратную связь, чтобы помочь студентам справиться с их уникальными трудностями и преуспеть в учебе.
😂 Перевод языков. Ну тут все понятно.
🎮Игровая индустрия: GPT-4 может помочь создать погружающиеся и динамичные сюжеты, генерируя диалоги и взаимодействия персонажей, которые кажутся более реалистичными и интересными.
🔥🔥🔥🔥Ну а мы тем временем готовим эфир совместно с Андреем Сундуковым, адептом чистого кода, Senior-разработчиком американской компании Step Mobile про то, как мы используем GPT-4. Андрей использует его как программист каждый день, я как не программист))
Поговорим про:
- как использовать GPT-4 эффективно
- какие ежедневные задачи может закрыть ИИ
- мои кейсы и кейсы Андрея, как мы их использовали и что из этого вышло
🚀🤖 Раскрываем сценарии использования в прямом эфире завтра 1 апреля в 11.00 по Москве по ссылке! 🤖🚀
PS: вступление и вот этот реплаенный пост сгенерированы GPT)))
🎮Игровая индустрия: GPT-4 может помочь создать погружающиеся и динамичные сюжеты, генерируя диалоги и взаимодействия персонажей, которые кажутся более реалистичными и интересными.
🔥🔥🔥🔥Ну а мы тем временем готовим эфир совместно с Андреем Сундуковым, адептом чистого кода, Senior-разработчиком американской компании Step Mobile про то, как мы используем GPT-4. Андрей использует его как программист каждый день, я как не программист))
Поговорим про:
- как использовать GPT-4 эффективно
- какие ежедневные задачи может закрыть ИИ
- мои кейсы и кейсы Андрея, как мы их использовали и что из этого вышло
🚀🤖 Раскрываем сценарии использования в прямом эфире завтра 1 апреля в 11.00 по Москве по ссылке! 🤖🚀
PS: вступление и вот этот реплаенный пост сгенерированы GPT)))
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
Заменит ли ChatGPT программистов? Обсуждение использования нейросети с Senior разработчиком
🔥 Запишись на курсы для инженеров, подними свою квалификацию на новый уровень: https://inzhenerka.tech/?utm_source=youtube_marybrenly
Канал Андрея в телеграмме https://t.me/developers_mind
Кто не слышал про ChatGPT? Какие возможности есть у нейросети,…
Канал Андрея в телеграмме https://t.me/developers_mind
Кто не слышал про ChatGPT? Какие возможности есть у нейросети,…
по мотивам использования ChatGPT написал в итоге статью с кучей рабочих скриншотов, читать тут:
https://ru.hexlet.io/blog/posts/chatgpt-kak-instrument-programmista
https://ru.hexlet.io/blog/posts/chatgpt-kak-instrument-programmista
Хекслет
8 полезных функций ChatGPT для программиста
Рассказываем, как разработчик с помощью ChatGPT может упростить себе работу и стоит ли вообще доверять нейросети писать код.
нашу прожарку заходов от рекрутеров полугодовой давности выложили на хабр:
https://habr.com/ru/articles/749992/
а вас что бесит в письмах от рекрутеров (кроме их отсутствия если вы только вкатываетесь 🥲) ?
https://habr.com/ru/articles/749992/
а вас что бесит в письмах от рекрутеров (кроме их отсутствия если вы только вкатываетесь 🥲) ?
Хабр
Зачем они пишут, что я крутой: разработчики комментируют письма рекрутеров
Мы попросили разработчиков прокомментировать реальные письма, которые прислали нам рекрутеры. Фил Ранжин и Андрей Сундуков в прямом эфире читали и оценивали сообщения, а мы сделали из этого статью —...
Заметил, что в добротном микросервисном проекте уже не такую большую роль играют правильные слои controller/service/db, потому что когда в принципе в сервисе 2-3 сущности (а в некоторых сервисах - одна), то и "толстый контроллер" в этом случае сложно получить, ну потому что размеры не позволят. Конечно, не привызваю всю логику писать в один слой, хотя бы даже потому что тогда тестирование будет затруднено, но удивляюсь насколько же высокоуровневая архитектура влияет на низкоуровневую организацию. И избавляет от старых болячек.
Еще одно следствие правильной микросервисной архитектуры - отсутствие высоких нагрузок в пересчете на сервис. В проекте, в котором работаю, зарегистрированны миллионы пользователей, сотни тысяч из которых совершают транзакции ежедневно. До такого уровня развития доживают считанные доли процентов проектов. И даже в такой ситуации в проекте нет никакого хайлоада или бигдаты. А из используемых технологий - Java, Postgres да Google Cloud. Да, даже кэш системы реализованы на основе СУБД. Очереди и асинхронная обработка - тоже базируются на базе данных и запускаются внутри сервисов, как Java классы из подключаемых зависимостей со своими конфигами.
И запаса по производительности еще кажется два порядка.
В итоге - не нужны дополнительные технологии, ни редисы и мемкеши, ни кафки и альтернативы с кучей обвязок типа дебезиума. А значит не нужны и отдельные инженеры или девопсы, которые умеют обслуживать и знают особенности дополнительных технологий. А все что нужно - люди, которые умеют работать с джавой и с постгресом. Более того, так как все технологии "in-house" - можно имплементировать самим дополнительные фичи если понадобится. По стабильности - меньше единых точек отказа, так как обычно всю инфрастуктуру обслуживает один кластер кафки и один кластер мемкеша. И по стоимости инфраструктуры - тоже выигрыш. На самом деле впервые столкнулся с таким подходом, но чем больше об этом думаю, тем больше вижу насколько много здесь очевидных плюсов.
И запаса по производительности еще кажется два порядка.
В итоге - не нужны дополнительные технологии, ни редисы и мемкеши, ни кафки и альтернативы с кучей обвязок типа дебезиума. А значит не нужны и отдельные инженеры или девопсы, которые умеют обслуживать и знают особенности дополнительных технологий. А все что нужно - люди, которые умеют работать с джавой и с постгресом. Более того, так как все технологии "in-house" - можно имплементировать самим дополнительные фичи если понадобится. По стабильности - меньше единых точек отказа, так как обычно всю инфрастуктуру обслуживает один кластер кафки и один кластер мемкеша. И по стоимости инфраструктуры - тоже выигрыш. На самом деле впервые столкнулся с таким подходом, но чем больше об этом думаю, тем больше вижу насколько много здесь очевидных плюсов.
KISS в архитектуре
Пару последних и несколько следующих постов хочется объединить этим заголовком. И для продолжения повествования - напомню что это такое:
KISS - Keep It Simple, (Stupid/Soldier/Sailor). Это принцип, который говорит что использование максимально простого подхода или решения предпочтительнее оверинжиниринга. С моей точки зрения это важно помнить и при написании кода, и при планировании базы данных, и при когда проектируете продукт любого масштаба.
И еще один термин который понадобится это:
Bus factor - неформальный термин относящийся к управлению проектами, который определяет количество критически важных сотрудников на проекте. Это то количество сотрудиков, попадание которых "под автобус", нанесет критически серьезный ущерб проекту. Например, если на проекте только один человек обладает специфичными знаниями, то bus factor равен единице. И это, разумеется, рискованно для проекта.
Небольшой и, наверное, очевидный спойлер: использование KISS на высокоуровневом проектировании проекта автоматически повышает bus factor и снижает риски для проекта.
Пару последних и несколько следующих постов хочется объединить этим заголовком. И для продолжения повествования - напомню что это такое:
KISS - Keep It Simple, (Stupid/Soldier/Sailor). Это принцип, который говорит что использование максимально простого подхода или решения предпочтительнее оверинжиниринга. С моей точки зрения это важно помнить и при написании кода, и при планировании базы данных, и при когда проектируете продукт любого масштаба.
И еще один термин который понадобится это:
Bus factor - неформальный термин относящийся к управлению проектами, который определяет количество критически важных сотрудников на проекте. Это то количество сотрудиков, попадание которых "под автобус", нанесет критически серьезный ущерб проекту. Например, если на проекте только один человек обладает специфичными знаниями, то bus factor равен единице. И это, разумеется, рискованно для проекта.
Небольшой и, наверное, очевидный спойлер: использование KISS на высокоуровневом проектировании проекта автоматически повышает bus factor и снижает риски для проекта.
KISS в ахритектуре
Возьмем две продуктовые компании.
Компания А разрабатывает продукт на стеке Java, PostgreSQL, Kafka, Redis, ElasticSearch и CI/CD наборе. Для упрощения предположим что у технологий одинаковая сложность равная единице. Итак, суммарная технологическая сложность продукта компании А - 6. Предположим средний сотрудник обладает 3 глубокими релевантными скилами по технологиям. Наняв 10 сотрудников получим среднее покрытие в виде 5 инженеров на технологию. Разумеется, Java и СУБД знает почти каждый инженер, а остальные технологии по остаточному принципу, но как минимум по 1-2 человека на технологию.
Компания B - разрабатывает аналогичный продукт на стеке Java, PostgreSQL и CI/CD наборе. Наняв 10 аналогичных сотрудников мы получим среднее покрытие в виде 10 человек на технологию. Следствием будет более высокий BusFactor и меньшие риски от ухода отдельных людей.
Пример, конечно, грубый. Но на личном опыте видел, как необоснованно внедренные технологии требовали буквально выделенных людей для поддержки этих технологий. Либо общий скилл инженеров был недостаточен и дополнительные технологии не добавляли никаких бонусов от использования. Дополнительные технологии так же влияют на сложность CI/CD процесса и стоимость инфраструктуры. Не говоря уж о том, что они добавляют новые точки отказа в продукт.
Этими примерами не пытаюсь призвать отказываться от технологий которые “на слуху”, но хочу обратить внимание что многие инженеры, кажется, очень легко соглашаются на внедрение тех или иных технологий, восхищаясь производительностью и ништяками, и слишком мало задумываясь о негативном влиянии того, с чем хотят "поиграться".
Возьмем две продуктовые компании.
Компания А разрабатывает продукт на стеке Java, PostgreSQL, Kafka, Redis, ElasticSearch и CI/CD наборе. Для упрощения предположим что у технологий одинаковая сложность равная единице. Итак, суммарная технологическая сложность продукта компании А - 6. Предположим средний сотрудник обладает 3 глубокими релевантными скилами по технологиям. Наняв 10 сотрудников получим среднее покрытие в виде 5 инженеров на технологию. Разумеется, Java и СУБД знает почти каждый инженер, а остальные технологии по остаточному принципу, но как минимум по 1-2 человека на технологию.
Компания B - разрабатывает аналогичный продукт на стеке Java, PostgreSQL и CI/CD наборе. Наняв 10 аналогичных сотрудников мы получим среднее покрытие в виде 10 человек на технологию. Следствием будет более высокий BusFactor и меньшие риски от ухода отдельных людей.
Пример, конечно, грубый. Но на личном опыте видел, как необоснованно внедренные технологии требовали буквально выделенных людей для поддержки этих технологий. Либо общий скилл инженеров был недостаточен и дополнительные технологии не добавляли никаких бонусов от использования. Дополнительные технологии так же влияют на сложность CI/CD процесса и стоимость инфраструктуры. Не говоря уж о том, что они добавляют новые точки отказа в продукт.
Этими примерами не пытаюсь призвать отказываться от технологий которые “на слуху”, но хочу обратить внимание что многие инженеры, кажется, очень легко соглашаются на внедрение тех или иных технологий, восхищаясь производительностью и ништяками, и слишком мало задумываясь о негативном влиянии того, с чем хотят "поиграться".
KISS в архитектуре
Нужен ли Redis?
Сразу оговорюсь - оцениваю технологии с высоты собственного опыта на PHP и Java-стеке. Если есть идеи или мысли что я что-то упустил или не так посчитал - обязательно пишите в комменты, обсудим!
Итак, давайте оценим Redis, как яркого представителя кэш систем, и оценим прирост производительности по сравнению с “только СУБД”. Не буду рассматривать сложные штуки, например дополнительные структуры типа списков, деревьев и блокировок. Предположу, что соотношение производительностей этих структур будет аналогичным.
Итак, по оценке ChatGPT на среднем современном сервере производительность Redis при работе в режиме key-value с 80% read нагрузкой и 20% write составляет 420к операций в секунду. Аналогичный вариант при работе с 2 столбцами primaryKey + text в одной таблице в PostgreSQL сможет выдать ~82к операций в секунду при условии что таблица достаточного размера, чтоб находиться постоянно в памяти. Для меня эти оценки выглядят очень реалистичными. Давайте скажем, что Redis в любом режиме выдает 5х производительности по сравнению с СУБД размеры данных в которой позволяют им всегда находиться в кеше. Много это или мало? Думаю, что достаточно ответить на вопрос - много ли проектов на нашем опыте действительно упираются в производительность СУБД по живой нагрузке, а не по причине неправильных, причем зачастую аналитических, запросов. За 12 лет опыта работы видел такие проекты только на сценах конференций. Это конечно интересно но правда ли redis нужен на конкретно вашем сегодняшнем проекте? Те мои проекты, которые использовали memcached или redis, могли бы положить их в общую бд с тем же результатом и с минимальными просадками по скорости работы. В абсолютном большинстве проектов где я работал 99% нагрузки на реляционную БД генерируется аналитическими запросами, и даже в этих случаях общая нагрузка на БД редко превышает 20-50%, иначе запускается очередной цикл оптимизации аналитических запросов силами инженеров.
В итоге, подозреваю, что 95-98% современных проектов могут легко обойтись без in-memory специализированных решений. Это позволяет тянуть меньше технологий в проект, упрощать схему инфраструктуры, уменьшать количество точек отказа, делать проще требования к новым инженерам. Звучит очень выгодно! А вы что думаете? ^^
P.S. я, конечно, тоже люблю делать производительные решения и достигать максимум возможного, но правда ли это нам надо на бизнес-проектах, которые не планирует пользоваться этой производительностью?
Нужен ли Redis?
Сразу оговорюсь - оцениваю технологии с высоты собственного опыта на PHP и Java-стеке. Если есть идеи или мысли что я что-то упустил или не так посчитал - обязательно пишите в комменты, обсудим!
Итак, давайте оценим Redis, как яркого представителя кэш систем, и оценим прирост производительности по сравнению с “только СУБД”. Не буду рассматривать сложные штуки, например дополнительные структуры типа списков, деревьев и блокировок. Предположу, что соотношение производительностей этих структур будет аналогичным.
Итак, по оценке ChatGPT на среднем современном сервере производительность Redis при работе в режиме key-value с 80% read нагрузкой и 20% write составляет 420к операций в секунду. Аналогичный вариант при работе с 2 столбцами primaryKey + text в одной таблице в PostgreSQL сможет выдать ~82к операций в секунду при условии что таблица достаточного размера, чтоб находиться постоянно в памяти. Для меня эти оценки выглядят очень реалистичными. Давайте скажем, что Redis в любом режиме выдает 5х производительности по сравнению с СУБД размеры данных в которой позволяют им всегда находиться в кеше. Много это или мало? Думаю, что достаточно ответить на вопрос - много ли проектов на нашем опыте действительно упираются в производительность СУБД по живой нагрузке, а не по причине неправильных, причем зачастую аналитических, запросов. За 12 лет опыта работы видел такие проекты только на сценах конференций. Это конечно интересно но правда ли redis нужен на конкретно вашем сегодняшнем проекте? Те мои проекты, которые использовали memcached или redis, могли бы положить их в общую бд с тем же результатом и с минимальными просадками по скорости работы. В абсолютном большинстве проектов где я работал 99% нагрузки на реляционную БД генерируется аналитическими запросами, и даже в этих случаях общая нагрузка на БД редко превышает 20-50%, иначе запускается очередной цикл оптимизации аналитических запросов силами инженеров.
В итоге, подозреваю, что 95-98% современных проектов могут легко обойтись без in-memory специализированных решений. Это позволяет тянуть меньше технологий в проект, упрощать схему инфраструктуры, уменьшать количество точек отказа, делать проще требования к новым инженерам. Звучит очень выгодно! А вы что думаете? ^^
P.S. я, конечно, тоже люблю делать производительные решения и достигать максимум возможного, но правда ли это нам надо на бизнес-проектах, которые не планирует пользоваться этой производительностью?
Коллеги, хочу немного свичнуться с темы Java на базы данных и в этот раз не рассказать что-то из головы, а спросить у вас.
Сейчас рассматриваю опции апгрейда наших миграций на текущем проекте. Сейчас это обычный flywaydb который на старте сервиса накатывает миграции. Достаточно топорно и просто. Возникла проблема с тем что на CI/CD стоят таймауты чтоб мониторить состояние поднимающихся подов и когда они заняты добавлением индексов или другими тяжелыми миграциями - они просто отваливаются по таймауту.
Думаем над несколькими возможными сценариями между запуском асинхронных миграций внутри такущего CI/CD или выносом миграций во внешнее репо, отвязывание их текущего деплойного процесса и разумеется еще "более асихнхронное" их выполнение.
Как на ваших проектах решается данная проблема? или может вам в последнее время попадались какие-то релевантные статьи или выступления? Буду очень признателен! а по итогам будет новая тема тут ^^
Сейчас рассматриваю опции апгрейда наших миграций на текущем проекте. Сейчас это обычный flywaydb который на старте сервиса накатывает миграции. Достаточно топорно и просто. Возникла проблема с тем что на CI/CD стоят таймауты чтоб мониторить состояние поднимающихся подов и когда они заняты добавлением индексов или другими тяжелыми миграциями - они просто отваливаются по таймауту.
Думаем над несколькими возможными сценариями между запуском асинхронных миграций внутри такущего CI/CD или выносом миграций во внешнее репо, отвязывание их текущего деплойного процесса и разумеется еще "более асихнхронное" их выполнение.
Как на ваших проектах решается данная проблема? или может вам в последнее время попадались какие-то релевантные статьи или выступления? Буду очень признателен! а по итогам будет новая тема тут ^^