Media is too big
VIEW IN TELEGRAM
Разглядываем Indie Hackers
🔥 💩 👍
Please open Telegram to view this post
VIEW IN TELEGRAM
Media is too big
VIEW IN TELEGRAM
С помощью чего организовать отправку email-ов для web-проекта
Forwarded from Anticode
Пару недель назад ко мне обратился заказчик с необычной просьбой реализовать фронтовую часть приложения, которое уже по всей видимости было разработано, на Directual, что само по себе мне показалось странным, потому что фронт – не сильная сторона Directual, в первую очередь это бэкенд и API. Соответственно, я стал задавать ему уточняющие вопросы и в итоге мы пришли к выводу, что нужно провести полноценную консультацию.
На этой консультации я выяснил, что само приложение сейчас реализовано на Bubble, а бэкенд разработан самостоятельно, то есть это не no-code. Проблема заключалась в том, что вся эта связка работает очень медленно и приложение неюзабельно с точки зрения пользователя. И задача команда разработки заключалась в том, чтобы перейти на новый фронт с Бабла.
Но самое ли это оптимальное решение в данной ситуации? И что меня больше всего насторожило – это то, что Bubble сейчас лидирует на рынке no-code и вряд ли им бы пользовалось такое количество людей, было собрано огромное комьюнити, они привлекли бы столько денег на развитие, если бы приложения, собранные на этой платформе, были не юзабелены.
К тому же я сам уже несколько лет вполне успешно использую Bubble для разных проектов, и он показывает себя очень хорошо, в том числе и скорости работы. Да, естественно, качественно и чисто написанный кастомный JavaScript или сайт, работающий на JamStack будет заметно быстрее с точки зрения пользователя. Но ничего критичного, что могло бы просто заруинить проект, как в случае с этим запросом, я точно не наблюдал.
Будем разбираться, в чём же тут дело, и как можно решить эту задачу.
На этой консультации я выяснил, что само приложение сейчас реализовано на Bubble, а бэкенд разработан самостоятельно, то есть это не no-code. Проблема заключалась в том, что вся эта связка работает очень медленно и приложение неюзабельно с точки зрения пользователя. И задача команда разработки заключалась в том, чтобы перейти на новый фронт с Бабла.
Но самое ли это оптимальное решение в данной ситуации? И что меня больше всего насторожило – это то, что Bubble сейчас лидирует на рынке no-code и вряд ли им бы пользовалось такое количество людей, было собрано огромное комьюнити, они привлекли бы столько денег на развитие, если бы приложения, собранные на этой платформе, были не юзабелены.
К тому же я сам уже несколько лет вполне успешно использую Bubble для разных проектов, и он показывает себя очень хорошо, в том числе и скорости работы. Да, естественно, качественно и чисто написанный кастомный JavaScript или сайт, работающий на JamStack будет заметно быстрее с точки зрения пользователя. Но ничего критичного, что могло бы просто заруинить проект, как в случае с этим запросом, я точно не наблюдал.
Будем разбираться, в чём же тут дело, и как можно решить эту задачу.
🤔1
Forwarded from Anticode
Стартап-проект, связка Bubble + самописный бэкенд. Проблема – сайт работает очень медленно, пользоваться невозможно.
В первую очередь надо посмотреть на архитектуру, каким образом наше приложение функционирует, какие у него есть составные части и что из них может быть основным тормозящим фактором? Потому что скорость каравана равна скорости самого медленного верблюда, и в данном случае нужно найти этого верблюда и попробовать его пришпорить.
Начнём с бэкенда – того, что скрыто под капотом. Программная часть, которая обрабатывает данные, работает с базой, в общем делает всё, что скрыто от глаз пользователя. В общей связке программного комплекса – это двигатель, от скорости работы которого в принципе зависит возможная потенциальная скорость всей машины.
В нашем случае движок работает на базе языка Go от Google, который сам по себе является довольно быстрым относительно других. Несложные проекты, реализованные на грамотно написанном коде Go точно не будут обделены скоростью, если не будет других тормозящих факторов. Разумеется, если он написан грамотно.
На данном этапе в сам код я не погружался, да это и не нужно для базовой оценки ситуации. Достаточно посмотреть на конечную скорость получения данных при запросах. То есть пользователь что-то делает на сайте (фронт, нажимает на педаль газа), фронт отправляет запрос к бэкенду (срабатывает передаточный механизм) и бэкенд возвращает данные (крутящий момент), фронт их отображает (колёса вращаются).
В данном случае мы видим, что данные по запросу возвращаются очень быстро, за доли секунды, ка кв принципе и должно быть. Отправили запрос – сервис ответил, скажем, за 0,25 секунды. Но на фронте данные появляются значительно позже, только секунд через 15-20.
Копаем дальше.
В первую очередь надо посмотреть на архитектуру, каким образом наше приложение функционирует, какие у него есть составные части и что из них может быть основным тормозящим фактором? Потому что скорость каравана равна скорости самого медленного верблюда, и в данном случае нужно найти этого верблюда и попробовать его пришпорить.
Начнём с бэкенда – того, что скрыто под капотом. Программная часть, которая обрабатывает данные, работает с базой, в общем делает всё, что скрыто от глаз пользователя. В общей связке программного комплекса – это двигатель, от скорости работы которого в принципе зависит возможная потенциальная скорость всей машины.
В нашем случае движок работает на базе языка Go от Google, который сам по себе является довольно быстрым относительно других. Несложные проекты, реализованные на грамотно написанном коде Go точно не будут обделены скоростью, если не будет других тормозящих факторов. Разумеется, если он написан грамотно.
На данном этапе в сам код я не погружался, да это и не нужно для базовой оценки ситуации. Достаточно посмотреть на конечную скорость получения данных при запросах. То есть пользователь что-то делает на сайте (фронт, нажимает на педаль газа), фронт отправляет запрос к бэкенду (срабатывает передаточный механизм) и бэкенд возвращает данные (крутящий момент), фронт их отображает (колёса вращаются).
В данном случае мы видим, что данные по запросу возвращаются очень быстро, за доли секунды, ка кв принципе и должно быть. Отправили запрос – сервис ответил, скажем, за 0,25 секунды. Но на фронте данные появляются значительно позже, только секунд через 15-20.
Копаем дальше.
Forwarded from Anticode
Что может тормозить web-приложение
Движок под капотом у нас быстрый, с этим разобрались. А что с лицевой частью, фронтэндом? Как я уже упоминал в первом посте, фронт собран на Bubble – на текущий момент лидирующая no-code платформа, которая очень много ресурсов вкладывает в ускорение работы приложений, которые собраны на ней.
На одном из своих проектов наблюдал эту картину воочию: стандартный слайдер-гармошка раньше открывался как-то дёргано и заметно для глаза медленно, причём там не было какого-то тяжёлого контента. Через некоторое время после очередного обновления Bubble слайдер стал работать безупречно плавно без всяких заметных глазу тормозов. При этом с моей стороны никаких изменений не было, обновилась сама платформа.
С тех пор прошло ещё несколько лет и улучшения производительности продолжают поступать. Поэтому обвинить Bubble в медленной работе я не могу, особенно когда вижу крупные серьёзные проекты, собранные на нём, которые привлекают миллионы долларов инвестиций. Значит, дело в чём-то другом.
И это другое может быть то, как приготовлен фронт на Bubble. Ведь это очень гибкий конструктор с полной свободой с точки зрения размещения контента и логики на нём. В отличие от простых конструкторов, которые просто не дают тебе испортить конечный продукт, так как просто ограничивают возможные действия пользователя жёсткими шаблонами.
Конструкторы вроде Tilda – это как поход в Макдак (и точка), где ты выбираешь из готовых блюд и на выходе получаешь ожидаемого качества обед. А Bubble – это магазин с ингредиентами, из которых тебе самому всё надо приготовить. Получится ли из этого шедевр или что-то, что придётся отдать коту, зависит полностью от тебя. Котяра, кстати, вероятно тоже не станет это употреблять.
Поэтому грамотно и чисто собранный Bubble – это важная составляющая быстрого приложения. Но это ещё не всё, остался ключевой элемент паззла.
Движок под капотом у нас быстрый, с этим разобрались. А что с лицевой частью, фронтэндом? Как я уже упоминал в первом посте, фронт собран на Bubble – на текущий момент лидирующая no-code платформа, которая очень много ресурсов вкладывает в ускорение работы приложений, которые собраны на ней.
На одном из своих проектов наблюдал эту картину воочию: стандартный слайдер-гармошка раньше открывался как-то дёргано и заметно для глаза медленно, причём там не было какого-то тяжёлого контента. Через некоторое время после очередного обновления Bubble слайдер стал работать безупречно плавно без всяких заметных глазу тормозов. При этом с моей стороны никаких изменений не было, обновилась сама платформа.
С тех пор прошло ещё несколько лет и улучшения производительности продолжают поступать. Поэтому обвинить Bubble в медленной работе я не могу, особенно когда вижу крупные серьёзные проекты, собранные на нём, которые привлекают миллионы долларов инвестиций. Значит, дело в чём-то другом.
И это другое может быть то, как приготовлен фронт на Bubble. Ведь это очень гибкий конструктор с полной свободой с точки зрения размещения контента и логики на нём. В отличие от простых конструкторов, которые просто не дают тебе испортить конечный продукт, так как просто ограничивают возможные действия пользователя жёсткими шаблонами.
Конструкторы вроде Tilda – это как поход в Макдак (и точка), где ты выбираешь из готовых блюд и на выходе получаешь ожидаемого качества обед. А Bubble – это магазин с ингредиентами, из которых тебе самому всё надо приготовить. Получится ли из этого шедевр или что-то, что придётся отдать коту, зависит полностью от тебя. Котяра, кстати, вероятно тоже не станет это употреблять.
Поэтому грамотно и чисто собранный Bubble – это важная составляющая быстрого приложения. Но это ещё не всё, остался ключевой элемент паззла.
Forwarded from Anticode
Последнее, что стоит изучить особенно пристально – это интеграционный слой или связка между бэкендом (движком) и фронтэндом (то, что видит пользователь). Если подкапотная часть работает как часы и экстерьер весь вылизан и отточен до совершенства (что само по себе редкость, кстати), то причина задержки с большой вероятностью кроется соединяющем их механизме.
Что происходит в процессе работы с web-приложением? Пользователь через браузер даёт какие-то команды, например, вывести каталог товаров. Фронт отправляет запрос к своему бэку, то есть кидает сигнал с просьбой прислать ему данные. Движок приложения, получив такой сигнал, бежит в базу данных, собирает всё, что нужно, в одну корзину и отправляет её обратно туда, откуда пришёл запрос. Вот эта часть, как мы выяснили ранее, работает быстро.
А дальше идёт процесс передачи данных из бэка на фронт. И вот тут может крыться корень зла. У тебя может быть полный резервуар воды, но если она подаётся через узкую трубочку диаметром с коктейльную соломинку, то наполняться бассейн будет мучительно долго.
Первый вопрос на макроуровне архитектуры. Где расположены серверы фронта и бэка? Так как фронт на Bubble – это серверные мощности Amazon В США.
Далее – самописный бэк. Его заказчик разместил на одном из своих хостингов, разумеется, в России. А теперь резонно подумать – а сколько времени будет идти порция данных с сервера в России на сервер в США? Учитывая при этом все возможные блокировки отдельных узлов и шлюзы, через которые должен пройти запрос-ответ в обе стороны. В общем путь неблизкий сам по себе.
Решение? Расположить серверы бэка и фронта как можно ближе друг к другу, чтобы как минимум исключить возможные задержки в связи с этим. Заставить Bubble переехать на другой сервер кажется задачей непростой, а вот свой собственный движок перенести на американский хостинг – задачка на час, которая может избавить от целого геморроя.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1
Forwarded from Anticode
Как ещё можно оптимизировать скорость работы web-приложения
Ещё одна точка преткновения, которую я обнаружил, консультируя заказчика – это объём передаваемых данных. Да, бэкенд работает молниеносно, API отвечает за доли секунды. Но порция данных, которую сервис вываливает на фронт – тысячи позиций за раз. А теперь приложению в браузере нужно как-то это всё прожевать, переварить и выдать полезные вещества из этих данных на экран.
А теперь и самому пользователю надо проделать всё то же самое: как-то воспринять этот объём информации и выудить оттуда нужное. Ведь у него и так мало инфы в течение дня: подумаешь, пара сотен постов в Инсте, с десяток умных каналов в Телеге (ага) и несколько видосов на Ютубе, просмотренных залпом.
Представь грузчика, который разгружает кузов, набитый небольшими коробками. если это самосвал, то можно опрокинуть его прямо на грузчика и уехать. Вот таким самосвалом сейчас API отгружает данные на фронт. Конечно, рано или поздно он всё разгребёт, но не будет ли более эффективным разбить данные на порции и подавать нашему работнику их партиями по 5 коробок за раз?
А теперь со стороны пользователя. Представь, что ты приходишь в аптеку и примерно знаешь, что тебе нужно приобрести. Говоришь это в окошке, а тебе приносят пару коробок, в которых свалены сотни разных лекарств, где точно есть искомое. Примерно так выглядят данные без фильтров на фронте.
Но ведь в жизни работает намного эффективнее, чем в некоторых приложениях! Ты подходишь к фармацевту, и он приносит тебе на твой запрос 2–4 варианта, из которых намного легче выбрать, задав ещё пару уточняющих вопросов. Это и есть фильтрация данных на фронте.
Итак, первое – фильтрация данных на входе. Разбей их на порции, добавь пагинацию (переключение страниц или подгрузка при скролле). Прикрути дополнительные фильтры, которые помогут вычленить нужное и ограничить выборку ещё больше. Тем самым облегчишь жизнь и бэку, и фронту, и пользователю.
Ещё одна точка преткновения, которую я обнаружил, консультируя заказчика – это объём передаваемых данных. Да, бэкенд работает молниеносно, API отвечает за доли секунды. Но порция данных, которую сервис вываливает на фронт – тысячи позиций за раз. А теперь приложению в браузере нужно как-то это всё прожевать, переварить и выдать полезные вещества из этих данных на экран.
А теперь и самому пользователю надо проделать всё то же самое: как-то воспринять этот объём информации и выудить оттуда нужное. Ведь у него и так мало инфы в течение дня: подумаешь, пара сотен постов в Инсте, с десяток умных каналов в Телеге (ага) и несколько видосов на Ютубе, просмотренных залпом.
Представь грузчика, который разгружает кузов, набитый небольшими коробками. если это самосвал, то можно опрокинуть его прямо на грузчика и уехать. Вот таким самосвалом сейчас API отгружает данные на фронт. Конечно, рано или поздно он всё разгребёт, но не будет ли более эффективным разбить данные на порции и подавать нашему работнику их партиями по 5 коробок за раз?
А теперь со стороны пользователя. Представь, что ты приходишь в аптеку и примерно знаешь, что тебе нужно приобрести. Говоришь это в окошке, а тебе приносят пару коробок, в которых свалены сотни разных лекарств, где точно есть искомое. Примерно так выглядят данные без фильтров на фронте.
Но ведь в жизни работает намного эффективнее, чем в некоторых приложениях! Ты подходишь к фармацевту, и он приносит тебе на твой запрос 2–4 варианта, из которых намного легче выбрать, задав ещё пару уточняющих вопросов. Это и есть фильтрация данных на фронте.
Итак, первое – фильтрация данных на входе. Разбей их на порции, добавь пагинацию (переключение страниц или подгрузка при скролле). Прикрути дополнительные фильтры, которые помогут вычленить нужное и ограничить выборку ещё больше. Тем самым облегчишь жизнь и бэку, и фронту, и пользователю.
🔥2
Forwarded from Anticode
Соберу воедино всё, на что стоит обратить внимание в первую очередь при анализе скорости работы web-проекта по мотивам консультации заказчика
1. Нужно определить узкое горлышко системы, самого медленного верблюда, который тормозит весь караван.
2. Для этого последовательно проверяем все составные элементы архитектуры. Разумеется, предварительно надо описать архитектуру хотя бы на верхнем уровне для понимания, с чем мы работаем.
3. Подкапотный движок или бэкенд – то, с чем следует начать анализ. Посмотри, как быстро он отрабатывает запросы, протестируй процесс получения данных и замерь скорость. Если она недостаточна, следует подумать над оптимизацией бэка.
4. Лицевая часть или фронтенд – то, с чем взаимодействует пользователь напрямую. Насколько быстра сама платформа, достаточно ли оптимально собрано приложение, нет ли лишний операций, которые можно переложить на плечи бэкенда?
5. Интеграционный слой – связь между бэком и фронтом. Насколько грамотно она организована, как далеко серверы расположены друг от друга, нет ли ограничений с обеих сторон (со стороны передачи или приёма)?
6. Оптимизация передачи данных. Разбить на порции, применить фильтры, ограничить поток.
И последнее. Переходить на новую платформу (как фронт, так и бэк) – всегда очень болезненный, долгий и ресурсоёмкий процесс. Если переводить в деньги, то сильно дешевле будет оптимизировать текущую конструкцию, чем строить новую.
Разумеется, есть случаи, когда неизбежен переход на новую архитектуру, например, когда упираемся в проблему масштабирования или технические ограничения платформ, но это тема для отдельной серии постов.
1. Нужно определить узкое горлышко системы, самого медленного верблюда, который тормозит весь караван.
2. Для этого последовательно проверяем все составные элементы архитектуры. Разумеется, предварительно надо описать архитектуру хотя бы на верхнем уровне для понимания, с чем мы работаем.
3. Подкапотный движок или бэкенд – то, с чем следует начать анализ. Посмотри, как быстро он отрабатывает запросы, протестируй процесс получения данных и замерь скорость. Если она недостаточна, следует подумать над оптимизацией бэка.
4. Лицевая часть или фронтенд – то, с чем взаимодействует пользователь напрямую. Насколько быстра сама платформа, достаточно ли оптимально собрано приложение, нет ли лишний операций, которые можно переложить на плечи бэкенда?
5. Интеграционный слой – связь между бэком и фронтом. Насколько грамотно она организована, как далеко серверы расположены друг от друга, нет ли ограничений с обеих сторон (со стороны передачи или приёма)?
6. Оптимизация передачи данных. Разбить на порции, применить фильтры, ограничить поток.
И последнее. Переходить на новую платформу (как фронт, так и бэк) – всегда очень болезненный, долгий и ресурсоёмкий процесс. Если переводить в деньги, то сильно дешевле будет оптимизировать текущую конструкцию, чем строить новую.
Разумеется, есть случаи, когда неизбежен переход на новую архитектуру, например, когда упираемся в проблему масштабирования или технические ограничения платформ, но это тема для отдельной серии постов.
Media is too big
VIEW IN TELEGRAM
Два крутейших AI-инструмента, которые сэкономят кучу денег и позволят создавать видео без камеры и микрофона
👍3
Media is too big
VIEW IN TELEGRAM
Свежие новости из мира искусственного интеллекта
1. Новая CocaCola с ИИ
2. Языковые модели от тех. гигантов в конкуренцию Chat-GPT
3. ИИ помог диагностировать болезнь у ребёнка, с чем не справились 17 врачей
1. Новая CocaCola с ИИ
2. Языковые модели от тех. гигантов в конкуренцию Chat-GPT
3. ИИ помог диагностировать болезнь у ребёнка, с чем не справились 17 врачей
👍2
Некоторое время назад писал о завершении одного крупного проекта, который мы делали с командой. С тех пор выдалось много интересных челленджей, которые выкладывал сюда в формате контента.
Но теперь всё-таки хочу вернуться к теме и продемонстрировать тебе результат кропотливой совместной работы заказчика и команды разработки с дизайнером. Это один из тех сайтов, про которые можно сказать Handmade с большой буквы: в нём нет ни одного шаблонного блока, всё это эксклюзивный ручной крафт, что только добавляет ему ценности.
Итак, с гордостью представляю сайт профессионального коуча с международными регалиями Ирины Виллемс willemsirina.com. можно поглазеть на скриншоты или лучше зайти на сам сайт – при живом просмотре другое впечатление. Плюс на сайте много интерактивных фишечек, которые будут заметны только при взаимодействии с ними, на плоских скринах не передать.
Надеюсь, ты получишь эстетическое удовольствие от визуала, а возможно и очень даже практическое.
Но теперь всё-таки хочу вернуться к теме и продемонстрировать тебе результат кропотливой совместной работы заказчика и команды разработки с дизайнером. Это один из тех сайтов, про которые можно сказать Handmade с большой буквы: в нём нет ни одного шаблонного блока, всё это эксклюзивный ручной крафт, что только добавляет ему ценности.
Итак, с гордостью представляю сайт профессионального коуча с международными регалиями Ирины Виллемс willemsirina.com. можно поглазеть на скриншоты или лучше зайти на сам сайт – при живом просмотре другое впечатление. Плюс на сайте много интерактивных фишечек, которые будут заметны только при взаимодействии с ними, на плоских скринах не передать.
Надеюсь, ты получишь эстетическое удовольствие от визуала, а возможно и очень даже практическое.
Хотел сегодня выложить своё видео, которое искусственный интеллект переведёт на японский. Записал, его, загрузил, а оказалось, что там очередь аж в 40 000 позиций.
Позиции меняются довольно быстро: раз в несколько секунд, поэтому я решил проверить, сколько же времени займёт всё это действо.
Ну и скоро увидим с тобой результат.
Позиции меняются довольно быстро: раз в несколько секунд, поэтому я решил проверить, сколько же времени займёт всё это действо.
Ну и скоро увидим с тобой результат.
На прошлой неделе на портале IndieHackers наткнулся на статью одного разработчика, который сделал сервис для скриншотов. Казалось бы, обычные скриншоты – базовая функция любой системы, что там ещё можно придумать? Ан нет, контент в масс-медиа требует красоты и дизайна – это именно то, что позволяют делать такие сервисы.
Если ты хочешь опубликовать какой-то скриншот, можно сделать это втупую, как я обычно и делаю, так как не любитель всяких рюшечек и наворотов, которые просто замыливают глаз и отвлекают от важных деталей. Однако эстетику и хороший дизайн я тоже люблю, поэтому, когда пришло время выставлять скриншоты сайта заказчика я подумал о том, что тут будет очень кстати окантовка в фирменных цветах, срезанные углы и объёмная тень.
Я сразу же вспомнил про сервис этого парня из статьи, но обнаружил, что он работает исключительно на Маках. На Маке я работаю во время поездок или когда нужна мобильность, в основное время – на Винде, поэтому я пошёл искать подходящий инструмент.
И я нашёл его – BrandBird, который работает в бразуере (читай – на любой платформе). Работает очень просто – загружаешь картинку и всё, так как есть готовые шаблоны, которые можно использовать сразу. Или можно с ними поиграться (как со шрифтами) и сделать тот визуал, какой хочется именно тебе, под нужный стиль или бренд.
Всё, что нужно, там есть, разобраться довольно легко. В бесплатной версии на картинке будет висеть шильдик сервиса. В платной версии его можно убрать. В бесплатной его тоже можно убрать в Фотошопе, конечно, но я считаю, что хорошими инструментами надо делиться, к тому же я только выиграю, если сервис будет развиваться.
Если ты хочешь опубликовать какой-то скриншот, можно сделать это втупую, как я обычно и делаю, так как не любитель всяких рюшечек и наворотов, которые просто замыливают глаз и отвлекают от важных деталей. Однако эстетику и хороший дизайн я тоже люблю, поэтому, когда пришло время выставлять скриншоты сайта заказчика я подумал о том, что тут будет очень кстати окантовка в фирменных цветах, срезанные углы и объёмная тень.
Я сразу же вспомнил про сервис этого парня из статьи, но обнаружил, что он работает исключительно на Маках. На Маке я работаю во время поездок или когда нужна мобильность, в основное время – на Винде, поэтому я пошёл искать подходящий инструмент.
И я нашёл его – BrandBird, который работает в бразуере (читай – на любой платформе). Работает очень просто – загружаешь картинку и всё, так как есть готовые шаблоны, которые можно использовать сразу. Или можно с ними поиграться (как со шрифтами) и сделать тот визуал, какой хочется именно тебе, под нужный стиль или бренд.
Всё, что нужно, там есть, разобраться довольно легко. В бесплатной версии на картинке будет висеть шильдик сервиса. В платной версии его можно убрать. В бесплатной его тоже можно убрать в Фотошопе, конечно, но я считаю, что хорошими инструментами надо делиться, к тому же я только выиграю, если сервис будет развиваться.
❤1
Sequoia – это один из самых крутых и могущественных венчурных фондов в мире (если не самый), благодаря которому достигли своих масштабов такие компании, как Apple, Instagram, Zoom, Airbnb, WhatsApp и множество других. Но это так, минутка образования в сфере венчурного капитализма.
А что я хотел показать – неделю назад они опубликовали статью с картой рынка генеративного искусственного интеллекта. То есть собрали в одном месте и аккуратно сгруппировали по категориям сервисы, которые задействуют под капотом ИИ, которые мы можем использовать себе во благо.
Собственно, делюсь с тобой этой картой. Уверен, что стоит как минимум обратить внимание на эти инструменты и некоторый из них положить в свой арсенал, ведь они могут помочь сэкономить время, ресурсы, деньги, хотя это только поверхностный слой того, что можно получить от ИИ уже сегодня. Пользуйся!
А что я хотел показать – неделю назад они опубликовали статью с картой рынка генеративного искусственного интеллекта. То есть собрали в одном месте и аккуратно сгруппировали по категориям сервисы, которые задействуют под капотом ИИ, которые мы можем использовать себе во благо.
Собственно, делюсь с тобой этой картой. Уверен, что стоит как минимум обратить внимание на эти инструменты и некоторый из них положить в свой арсенал, ведь они могут помочь сэкономить время, ресурсы, деньги, хотя это только поверхностный слой того, что можно получить от ИИ уже сегодня. Пользуйся!
🔥1