Anticodeguy

⚠️ Не попадись на мошенничество! Последний пост натолкнул меня на мысли о следующем. Мы живём с тобой в настоящем киберпанке, это уже давно не будущее, но то, что окружает нас уже сейчас. Нажатием кнопки можно сгенерировать видео с участием любого человека, на котором он будет своим голосом говорить заданный текст. Подделать можно всё: фотографии, голос, видео. Можно даже задать нейронке твою манеру говорить и строить предложения и результат будет просто неотличим от оригинала. Теперь представь, какие возможности это открывает мошенникам… Тебе может «позвонить» сын, сестра, отец, близкий друг и своим собственным «голосом» в собственной манере попросить одолжить денег, рассказав попутно трогательную историю, которая точно не оставит тебя равнодушным. А теперь ещё сможет и видео прислать с подтверждением собственных слов. Мы тут с тобой держимся на пике технологий, изучаем их и стараемся быть осведомлёнными. Но большинство людей понятия не имеют, что такое искусственный интеллект и на что он способен уже сегодня. Особенно люди старшего возраста, которым будет сложно объяснить, как это работает. Но всё же сделать это считаю необходимым. Расскажи своим близким, что такое существует, предупреди, чтобы не отдавали деньги кому-то, позвонившему или написавшему с другого номера, даже если это был реальный голос родственника. Да и ты не забывай проверять лишний раз.

Помнишь, как в Матрице Нео выучил за несколько секунд кунг-фу? На изучение японского мне потребовалось немного больше времени, да и это не совсем я, а скорее мой цифровой аватар. Но всё же он говорит на идеальном японском моим голосом, что наглядно видно на видео. Если вдруг кто знает японский, проверьте, насколько грамотно сделан перевод.

Я тут пропал с радаров, а всё потому что на днях получил визу в Сингапур и сейчас тут, нахаживаю десятки тысяч шагов по невероятному городу и наслаждаюсь его безумной динамикой и энергией. Особенно на контрасте со спокойным и размеренным Таиландом Сингапур кажется воплощением чистого драйва и буйства человеческого креатива. Так что жди в ближайшее время контент другого формата: про мои путешествия и впечатления от самого дорого города в мире. Кстати, он ещё на мой взгляд и самый современный и передовой в плане технологий. Всё можно сделать в цифровом виде: от въездной визы до регистрации бизнеса. На скрине как раз моя цифровая виза: никаких бумажек и даже штамп в паспорт не ставят.

Есть такой известный медийный персонаж Лекс Фридман, который ведёт подкаст в формате интервью с разными известными людьми. Подкасты обычно слушают и выходят они в аудиоформате, но часто к ним прилагается YouTube-канал с видеорядом и в данном случае видео имеет ключевую роль. Сегодня у Фридмана вышло видеоинтервью с Марком Цукербергом, которое прошло полностью в метавселенной. На обоих были надеты шлемы виртуальной реальности Oculus и в этих шлемах они видели друг друга на расстоянии вытянутой руки. Хотя физически при этом находились в разных городах. Видели они при этом не друг друга, а превосходно реализованные трёхмерные модели себя же. Модели или аватары создаются с помощью технологии трёхмерного сканирования, похожее сейчас применяется много где, от игровой индустрии до архитектуры. При этом сканируется не просто статичный болванчик, а разные позы, движения в динамике, мимика и выражение различных эмоций. В итоге получается аватар, который в точности повторяет движения губ, все морщинки и движения скул, моргание глаз и выглядит так, что сложно отличить от живого человека. Пока выглядит всё как невероятная и ненужная игрушка из научной фантастики, но на деле это уже довольно хорошо отработанная технология, которая вот-вот войдёт в массовый рынок. Да, шлемы пока неудобные, большие и дорогие, но Apple уже готовит свою версию, которая, я уверен, распространит дополненную реальность широко. А за ней и виртуальная подтянется. Пиши в комментах, что думаешь про это. Ссылка на видео: https://youtu.be/MVYrJJNdrEg?si=36otXXUsWwYkzjgu

Sequoia – это один из самых крутых и могущественных венчурных фондов в мире (если не самый), благодаря которому достигли своих масштабов такие компании, как Apple, Instagram, Zoom, Airbnb, WhatsApp и множество других. Но это так, минутка образования в сфере венчурного капитализма. А что я хотел показать – неделю назад они опубликовали статью с картой рынка генеративного искусственного интеллекта. То есть собрали в одном месте и аккуратно сгруппировали по категориям сервисы, которые задействуют под капотом ИИ, которые мы можем использовать себе во благо. Собственно, делюсь с тобой этой картой. Уверен, что стоит как минимум обратить внимание на эти инструменты и некоторый из них положить в свой арсенал, ведь они могут помочь сэкономить время, ресурсы, деньги, хотя это только поверхностный слой того, что можно получить от ИИ уже сегодня. Пользуйся!

На прошлой неделе на портале IndieHackers наткнулся на статью одного разработчика, который сделал сервис для скриншотов. Казалось бы, обычные скриншоты – базовая функция любой системы, что там ещё можно придумать? Ан нет, контент в масс-медиа требует красоты и дизайна – это именно то, что позволяют делать такие сервисы. Если ты хочешь опубликовать какой-то скриншот, можно сделать это втупую, как я обычно и делаю, так как не любитель всяких рюшечек и наворотов, которые просто замыливают глаз и отвлекают от важных деталей. Однако эстетику и хороший дизайн я тоже люблю, поэтому, когда пришло время выставлять скриншоты сайта заказчика я подумал о том, что тут будет очень кстати окантовка в фирменных цветах, срезанные углы и объёмная тень. Я сразу же вспомнил про сервис этого парня из статьи, но обнаружил, что он работает исключительно на Маках. На Маке я работаю во время поездок или когда нужна мобильность, в основное время – на Винде, поэтому я пошёл искать подходящий инструмент. И я нашёл его – BrandBird, который работает в бразуере (читай – на любой платформе). Работает очень просто – загружаешь картинку и всё, так как есть готовые шаблоны, которые можно использовать сразу. Или можно с ними поиграться (как со шрифтами) и сделать тот визуал, какой хочется именно тебе, под нужный стиль или бренд. Всё, что нужно, там есть, разобраться довольно легко. В бесплатной версии на картинке будет висеть шильдик сервиса. В платной версии его можно убрать. В бесплатной его тоже можно убрать в Фотошопе, конечно, но я считаю, что хорошими инструментами надо делиться, к тому же я только выиграю, если сервис будет развиваться.

Хотел сегодня выложить своё видео, которое искусственный интеллект переведёт на японский. Записал, его, загрузил, а оказалось, что там очередь аж в 40 000 позиций. Позиции меняются довольно быстро: раз в несколько секунд, поэтому я решил проверить, сколько же времени займёт всё это действо. Ну и скоро увидим с вами результат.

Некоторое время назад писал о завершении одного крупного проекта, который мы делали с командой. С тех пор выдалось много интересных челленджей, которые выкладывал сюда в формате контента. Но теперь всё-таки хочу вернуться к теме и продемонстрировать тебе результат кропотливой совместной работы заказчика и команды разработки с дизайнером. Это один из тех сайтов, про которые можно сказать Handmade с большой буквы: в нём нет ни одного шаблонного блока, всё это эксклюзивный ручной крафт, что только добавляет ему ценности. Итак, с гордостью представляю сайт профессионального коуча с международными регалиями Ирины Виллемс willemsirina.com. можно поглазеть на скриншоты или лучше зайти на сам сайт – при живом просмотре другое впечатление. Плюс на сайте много интерактивных фишечек, которые будут заметны только при взаимодействии с ними, на плоских скринах не передать. Надеюсь, ты получишь эстетическое удовольствие от визуала, а возможно и очень даже практическое.

Свежие новости из мира искусственного интеллекта 1. Новая CocaCola с ИИ 2. Языковые модели от тех. гигантов в конкуренцию Chat-GPT 3. ИИ помог диагностировать болезнь у ребёнка, с чем не справились 17 врачей

Два крутейших AI-инструмента, которые сэкономят кучу денег и позволят создавать видео без камеры и микрофона

Соберу воедино всё, на что стоит обратить внимание в первую очередь при анализе скорости работы web-проекта по мотивам консультации заказчика 1. Нужно определить узкое горлышко системы, самого медленного верблюда, который тормозит весь караван. 2. Для этого последовательно проверяем все составные элементы архитектуры. Разумеется, предварительно надо описать архитектуру хотя бы на верхнем уровне для понимания, с чем мы работаем. 3. Подкапотный движок или бэкенд – то, с чем следует начать анализ. Посмотри, как быстро он отрабатывает запросы, протестируй процесс получения данных и замерь скорость. Если она недостаточна, следует подумать над оптимизацией бэка. 4. Лицевая часть или фронтенд – то, с чем взаимодействует пользователь напрямую. Насколько быстра сама платформа, достаточно ли оптимально собрано приложение, нет ли лишний операций, которые можно переложить на плечи бэкенда? 5. Интеграционный слой – связь между бэком и фронтом. Насколько грамотно она организована, как далеко серверы расположены друг от друга, нет ли ограничений с обеих сторон (со стороны передачи или приёма)? 6. Оптимизация передачи данных. Разбить на порции, применить фильтры, ограничить поток. И последнее. Переходить на новую платформу (как фронт, так и бэк) – всегда очень болезненный, долгий и ресурсоёмкий процесс. Если переводить в деньги, то сильно дешевле будет оптимизировать текущую конструкцию, чем строить новую. Разумеется, есть случаи, когда неизбежен переход на новую архитектуру, например, когда упираемся в проблему масштабирования или технические ограничения платформ, но это тема для отдельной серии постов.

Как ещё можно оптимизировать скорость работы web-приложения Ещё одна точка преткновения, которую я обнаружил, консультируя заказчика – это объём передаваемых данных. Да, бэкенд работает молниеносно, API отвечает за доли секунды. Но порция данных, которую сервис вываливает на фронт – тысячи позиций за раз. А теперь приложению в браузере нужно как-то это всё прожевать, переварить и выдать полезные вещества из этих данных на экран. А теперь и самому пользователю надо проделать всё то же самое: как-то воспринять этот объём информации и выудить оттуда нужное. Ведь у него и так мало инфы в течение дня: подумаешь, пара сотен постов в Инсте, с десяток умных каналов в Телеге (ага) и несколько видосов на Ютубе, просмотренных залпом. Представь грузчика, который разгружает кузов, набитый небольшими коробками. если это самосвал, то можно опрокинуть его прямо на грузчика и уехать. Вот таким самосвалом сейчас API отгружает данные на фронт. Конечно, рано или поздно он всё разгребёт, но не будет ли более эффективным разбить данные на порции и подавать нашему работнику их партиями по 5 коробок за раз? А теперь со стороны пользователя. Представь, что ты приходишь в аптеку и примерно знаешь, что тебе нужно приобрести. Говоришь это в окошке, а тебе приносят пару коробок, в которых свалены сотни разных лекарств, где точно есть искомое. Примерно так выглядят данные без фильтров на фронте. Но ведь в жизни работает намного эффективнее, чем в некоторых приложениях! Ты подходишь к фармацевту, и он приносит тебе на твой запрос 2–4 варианта, из которых намного легче выбрать, задав ещё пару уточняющих вопросов. Это и есть фильтрация данных на фронте. Итак, первое – фильтрация данных на входе. Разбей их на порции, добавь пагинацию (переключение страниц или подгрузка при скролле). Прикрути дополнительные фильтры, которые помогут вычленить нужное и ограничить выборку ещё больше. Тем самым облегчишь жизнь и бэку, и фронту, и пользователю.

🌐 Ключевой сегмент в работе web-приложения Последнее, что стоит изучить особенно пристально – это интеграционный слой или связка между бэкендом (движком) и фронтэндом (то, что видит пользователь). Если подкапотная часть работает как часы и экстерьер весь вылизан и отточен до совершенства (что само по себе редкость, кстати), то причина задержки с большой вероятностью кроется соединяющем их механизме. Что происходит в процессе работы с web-приложением? Пользователь через браузер даёт какие-то команды, например, вывести каталог товаров. Фронт отправляет запрос к своему бэку, то есть кидает сигнал с просьбой прислать ему данные. Движок приложения, получив такой сигнал, бежит в базу данных, собирает всё, что нужно, в одну корзину и отправляет её обратно туда, откуда пришёл запрос. Вот эта часть, как мы выяснили ранее, работает быстро. А дальше идёт процесс передачи данных из бэка на фронт. И вот тут может крыться корень зла. У тебя может быть полный резервуар воды, но если она подаётся через узкую трубочку диаметром с коктейльную соломинку, то наполняться бассейн будет мучительно долго. Первый вопрос на макроуровне архитектуры. Где расположены серверы фронта и бэка? Так как фронт на Bubble – это серверные мощности Amazon В США. Далее – самописный бэк. Его заказчик разместил на одном из своих хостингов, разумеется, в России. А теперь резонно подумать – а сколько времени будет идти порция данных с сервера в России на сервер в США? Учитывая при этом все возможные блокировки отдельных узлов и шлюзы, через которые должен пройти запрос-ответ в обе стороны. В общем путь неблизкий сам по себе. Решение? Расположить серверы бэка и фронта как можно ближе друг к другу, чтобы как минимум исключить возможные задержки в связи с этим. Заставить Bubble переехать на другой сервер кажется задачей непростой, а вот свой собственный движок перенести на американский хостинг – задачка на час, которая может избавить от целого геморроя.

Что может тормозить web-приложение Движок под капотом у нас быстрый, с этим разобрались. А что с лицевой частью, фронтэндом? Как я уже упоминал в первом посте, фронт собран на Bubble – на текущий момент лидирующая no-code платформа, которая очень много ресурсов вкладывает в ускорение работы приложений, которые собраны на ней. На одном из своих проектов наблюдал эту картину воочию: стандартный слайдер-гармошка раньше открывался как-то дёргано и заметно для глаза медленно, причём там не было какого-то тяжёлого контента. Через некоторое время после очередного обновления Bubble слайдер стал работать безупречно плавно без всяких заметных глазу тормозов. При этом с моей стороны никаких изменений не было, обновилась сама платформа. С тех пор прошло ещё несколько лет и улучшения производительности продолжают поступать. Поэтому обвинить Bubble в медленной работе я не могу, особенно когда вижу крупные серьёзные проекты, собранные на нём, которые привлекают миллионы долларов инвестиций. Значит, дело в чём-то другом. И это другое может быть то, как приготовлен фронт на Bubble. Ведь это очень гибкий конструктор с полной свободой с точки зрения размещения контента и логики на нём. В отличие от простых конструкторов, которые просто не дают тебе испортить конечный продукт, так как просто ограничивают возможные действия пользователя жёсткими шаблонами. Конструкторы вроде Tilda – это как поход в Макдак (и точка), где ты выбираешь из готовых блюд и на выходе получаешь ожидаемого качества обед. А Bubble – это магазин с ингредиентами, из которых тебе самому всё надо приготовить. Получится ли из этого шедевр или что-то, что придётся отдать коту, зависит полностью от тебя. Котяра, кстати, вероятно тоже не станет это употреблять. Поэтому грамотно и чисто собранный Bubble – это важная составляющая быстрого приложения. Но это ещё не всё, остался ключевой элемент паззла.

Стартап-проект, связка Bubble + самописный бэкенд. Проблема – сайт работает очень медленно, пользоваться невозможно. В первую очередь надо посмотреть на архитектуру, каким образом наше приложение функционирует, какие у него есть составные части и что из них может быть основным тормозящим фактором? Потому что скорость каравана равна скорости самого медленного верблюда, и в данном случае нужно найти этого верблюда и попробовать его пришпорить. Начнём с бэкенда – того, что скрыто под капотом. Программная часть, которая обрабатывает данные, работает с базой, в общем делает всё, что скрыто от глаз пользователя. В общей связке программного комплекса – это двигатель, от скорости работы которого в принципе зависит возможная потенциальная скорость всей машины. В нашем случае движок работает на базе языка Go от Google, который сам по себе является довольно быстрым относительно других. Несложные проекты, реализованные на грамотно написанном коде Go точно не будут обделены скоростью, если не будет других тормозящих факторов. Разумеется, если он написан грамотно. На данном этапе в сам код я не погружался, да это и не нужно для базовой оценки ситуации. Достаточно посмотреть на конечную скорость получения данных при запросах. То есть пользователь что-то делает на сайте (фронт, нажимает на педаль газа), фронт отправляет запрос к бэкенду (срабатывает передаточный механизм) и бэкенд возвращает данные (крутящий момент), фронт их отображает (колёса вращаются). В данном случае мы видим, что данные по запросу возвращаются очень быстро, за доли секунды, ка кв принципе и должно быть. Отправили запрос – сервис ответил, скажем, за 0,25 секунды. Но на фронте данные появляются значительно позже, только секунд через 15-20. Копаем дальше.

Пару недель назад ко мне обратился заказчик с необычной просьбой реализовать фронтовую часть приложения, которое уже по всей видимости было разработано, на Directual, что само по себе мне показалось странным, потому что фронт – не сильная сторона Directual, в первую очередь это бэкенд и API. Соответственно, я стал задавать ему уточняющие вопросы и в итоге мы пришли к выводу, что нужно провести полноценную консультацию. На этой консультации я выяснил, что само приложение сейчас реализовано на Bubble, а бэкенд разработан самостоятельно, то есть это не no-code. Проблема заключалась в том, что вся эта связка работает очень медленно и приложение неюзабельно с точки зрения пользователя. И задача команда разработки заключалась в том, чтобы перейти на новый фронт с Бабла. Но самое ли это оптимальное решение в данной ситуации? И что меня больше всего насторожило – это то, что Bubble сейчас лидирует на рынке no-code и вряд ли им бы пользовалось такое количество людей, было собрано огромное комьюнити, они привлекли бы столько денег на развитие, если бы приложения, собранные на этой платформе, были не юзабелены. К тому же я сам уже несколько лет вполне успешно использую Bubble для разных проектов, и он показывает себя очень хорошо, в том числе и скорости работы. Да, естественно, качественно и чисто написанный кастомный JavaScript или сайт, работающий на JamStack будет заметно быстрее с точки зрения пользователя. Но ничего критичного, что могло бы просто заруинить проект, как в случае с этим запросом, я точно не наблюдал. Будем разбираться, в чём же тут дело, и как можно решить эту задачу.

С помощью чего организовать отправку email-ов для web-проекта

Как работает email-рассылка из web-приложения

Разглядываем Indie Hackers 🔥💩👍