👇🏿 Пишите, на сколько вопросов правильно ответили.👇🏿
Кстати, в 4 вопросе правильные ответы объём оперативной памяти, мощность процессора и размер файлов в приложении

→ Ставьте огонёк, если понравился опрос 🔥
→ Если что-то не понимаете, пишите комментарий. Объясню👇🏿
____
Опрос по статьям: часть 1 и часть 2

День 5/30

В этой статье написал об ограничениях со стороны Bubble, с которыми можно столкнуться при разработке приложения.

Думаю, автор книги всё же написал не все ограничения. Наверняка, если подумать, то можно выцепить ещё. Поэтому если что-то у вас есть на уме, то пишите в комменты. Дополним публикацию вместе.

В следующих публикациях будут конкретные шаги, чтобы оптимизировать производительность приложения на Bubble.

→ Ставьте огонь 🔥, если нравится то, чем делюсь с вами.
→ Читать статью (кликните)

День 6/30

Сегодняшние заметки с практическими советами, которые помогут ускорить приложение.

→ Ставьте 🔥, если читайте публикации.
→ Ставьте 💩, если хотите другой контент и напишите, в комменты, что хотите

День 7/30. BAS и автотестирование Bubble.

Сегодня я без заметок. Вместо этого расскажу про Nocode-инструмент — Browser Automation Studio (BAS).

Этот конструктор позволяет собирать скрипты разной сложности.
К примеру, я использовал его для создания:
1. Автопостера статей для Дзена
2. Авторегера аккаунтов для Дзена

Рассказал Дену об этом софте, и Ден закинул мысль про тестирование приложений на Bubble.

Интересная идея. Я реализовал её в примитивном варианте.
На видео вы можете лицезреть тестирование формы регистрации:
→ вводит логин
→ вводит пароль
→ нажимает зарегистрироваться
→ ждёт 5 секунд
→ делает скриншот экрана

По логам и результату на скрине можем понять, правильно ли отработало приложение.

Для вас записал 2 исхода:
1. Приложение зарегалось
2. Приложение не зарегалось из-за ошибки.

Польза подобного подхода к тестированию в том, что это разгружает разраба.
Пока софт ответственно тестирует заданные сценарии, разработчик занимается проработкой логики непосредственно.

→ Ставьте 🔥 под постом.
→ Пишите в комменты, что думаете о таком тестировании?
https://www.youtube.com/watch?v=s1f-d-25gvA

Решил собрать авторские каналы про ноукод разработку, чтобы вы всегда могли найти что-то полезное для себя😉 Если вы вдруг ведёте свой канал, то присылайте ссылку в комментах - буду дополнять подборку

https://t.me/pro_nocode - нескромно поставлю наш канал первым:) собираем полезные хаки и советы по Bubble, планируем расширяться в сторону других инструментов. Канал чисто для разработчиков и тех, кто хочет на этом зарабатывать.

https://t.me/revbubbledev - канал Вити Решетняка про bubble. Вместе работали. Собирает и находит крутые вещи про Bubble. Докапывается до мелочей - поэтому точно будет интересно читать

https://t.me/necoder_ru - канал Вани Вахрушева. Тоже работали вместе. Миксует как прикладной, так и личный контент. Интересно.

https://t.me/Tim_nocode - свежий канал от Тимофея. Уверен, что тоже будет супер полезно и интересно.

https://t.me/failblog - канал фаундера ноукод студии. Прикладной инфо по разработке нет, но полезно почитать про то, какие сложности бывают при управлении своей студии

https://t.me/denonline - канал Дэна. Дэн топ спец в ноукод инструментах, поэтому жду, когда там начнёт появляться контент.

https://t.me/ProNoCode - канал фаундера Creatium. Интересно наблюдать за тем, как развивается целый ноукод инструмент

https://t.me/noosfera_IT - канал про ноукод и жизнь ноукод разработчика. Прикладной и жизненный контент. Интересно следить.

https://t.me/georgystories - лично с автором не знаком. Пишет про вебфлоу, проводит стримы и делится полезностями

https://t.me/ne_koder - канал Димы Федосеева про Bubble. Наверное, самый топовый по качеству на данный момент. Жаль, что не так много контента, как хотелось бы:)

https://t.me/codewords - канал студии мобильной разработки от @ilyatkach

https://t.me/sashadontcode - канал про ноукод от @alexanderolssen

День 8/30.

Заметки с практическими советами по производительности приложений на Bubble.

Превьюшка интригующая 😁

→ Ставьте 🔥 под постом.
→ Используете уже что-то из предложенного в посте?

День 9/30. Как трекать время.

Вопрос, который меня беспокоит — учитывать ли время, которое уходит на перерывы?

На данный момент я трекаю только концентрированное рабочее время. Перерывы не учитываю. Получается, что если платят за часы, то конкретно мне платят только за моё концентрированное рабочее время.

Скажем из 8 часов, у меня концентрированного времени вышло на 6 часов, т.е. затреканного. В это время я добросовестно погружался в рабочие задачи и работал над ними. Остальные 2 часа ушли на перерывы.

Что если я договорился на 40 часов еженедельно?
Если на 8 часов приходится только 6 рабочих часов, то за неделю — это 30 рабочих часов. За месяц — 120. Получается, что при стандартном раскладе в 160 часов в месяц, я буду 40 часов из них отдыхать.

Вероятнее всего у заказчика появятся вопрос — какого ты так много отдыхаешь?

→ Напишите, в комментариях, пожалуйста, как вы засекаете рабочее время, и что подразумеваете под рабочим временем?
→ Если вы владеете студией, то напишите, что для вас — рабочее время сотрудника?

День 10/30.

Спасибо за активность в комментах в посте выше, ребятки 🔥

Напишу то, что отметил для себя:
- Трекинг — инвестиция в своё будущее, как разработчика. Узнал, сколько потратил на задачу сегодня, завтра — можешь её оценить и выставить правильный ценник.
- Работать эффективно не получится больше 5-6 часов в день.
- Созвоны с заказчиками должны оплачиваться.

А теперь к заметкам 👇

Заметки. Часть 6. Сервер, клиент и фильтрация.

В каких случаях стоит перенести на сторону клиента фильтрацию, чтобы ускорить приложение?

Читайте в заметках.

____
→ Ставьте огонёчки 🔥 под этим постом.
→ Оставляйте комменты.

День 11/30.

Сегодня в заметках накидал для вас материальчик по частичной оптимизации БД.

→ Залетайте, читайте, ставьте на пост лайки, если он зашёл, естественно.
→ И оставляйте комментарии.

Залетайте в чатик канала.
https://t.me/Discution_necoders

День 12/30

Сегодня в заметках про списки и поиск.

Залетаем, читаем. Пишем, понятно или нет.
Я пытаюсь распаковывать инфу доступно. Если вы не вдупляете что-то, пишите — это будет хорошим сигналом, глубже прорабатывать статьи.

→ Если вам статья зашла, лупите "реакцию" на пост. Мне будет приятно

День 13/30

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

Сами как хотите: видос или текст со скринами? → пишите в комменты.

→ Если материал был полезен для вас — лупите огонь 🔥

День 14/30

После публикации предыдущего поста у некоторых ребят возник вопрос "чо ты сказал, как не надо делать, а как надо не сказал?".

Короче, вчера написал в чатике про тему с группировкой, но это не самая удачная идея. Сегодня придумал способ, который будет эффективнее и проще. Поэтому про группировку расскажу в другой раз.

Возьмем пример с подсчетом статей:
В RG выводим имя пользователя и количество статей, которое он прочитал.
Как сделать так, чтобы вот это самое количество не приходилось подсчитывать для каждого пользователя на сервере?
Очень просто.

Для этого нам нужно создать в сущности User ещё одно поле "countOfArticles", куда мы будем складывать количество прочитанных статей.
То есть каждый раз, когда пользователь читает статью, делаем в этом поле +1.

Таким образом, когда будем подгружать пользователей в RG, у нас уже будет известно количество прочитанных статей для каждого пользователя. То есть 500 поисков дополнительно мы делать не будем, а ограничимся одним – по пользователям (Search for Users)

Вот так вот просто.
____
→ Если у вас есть другие варианты решения этой задачки – пишите в комменты.
→ Ну и кидайте вопросы, конечно же.

День 15/30.

Очередная серия заметок. Сегодня про комбинирование типов данных.
Мой рекомендасьон - сделать на практике пример из статьи. Так лучше впитаете.

→ Читать статью
→ Реакций насыпьте, если нравится контент 🔥

Производительность приложений на Bubble:

Часть 1. Слои приложения. Виды производительности.
Часть 2. Производительность Bubble, производительность устройства.
Часть 3. Ограничения Bubble.
Часть 4. Оптимизация приложения.
Часть 5. Одностраничное или многостраничное.
Часть 6. Фильтрация.
Часть 7. Оптимизация структуры БД.
Часть 8. Список (list) и поиск
Часть 9. Эффективный поиск.
Пример решения эффективного поиска.
Часть 10. Комбинирование типов данных.
Часть 11. Поиск разных типов данных.
Часть 12. Выносим "тяжёлое" в другую сущность.
Часть 13. Креативные option sets.
Часть 14. Ответ приложения на действия пользователя.
Часть 15. Ускоряем workflow.
Часть 16. Не повторяйся.
Часть 17. Бэкенд: триггеры и циклы.
Часть 18. Триггеры.
Часть 19. Прозрачное общение.

День 16/30.

Раскидал немножко инфы из книги.
Сегодня материала прям совсем мало. Минуты 2 уйдёт с учётом того, что ещё и вникнуть нужно.

Чёт мне кажется, автор допустил ошибку в следующем блоке (кстати, поэтому его не выкатил сегодня). Завтра разберу его, въеду в него и выкачу вам.
____
И ещё немного инфы:

Пару дней назад провёл консультацию для Кирилла. Кирилл приходит второй раз, первый раз помогал ему решить задачку с тестовым заданием в компанию, куда он устраивался.
Сейчас он работает в ней уже 3 месяца и неплохо разбирается в Bubble.

В этот раз запрос был такой — Как добавлять участников проекта в группой чат?

Функционал чата уже был реализован.
Немного изменили сущность и прикрутили вф на бэке, который не сработал из-за free тарифа. Поэтому пока собрали временное решение на фронте.
Думаю, Кирилл перекинет логику после апдейта тарифа, и всё ок будет.

Помню себя, когда только начинал изучать Bubble:
К примеру, кастом стейты дались мне не с первого раза. Просидел за ними пару дней, прежде чем понял, как они вообще работают))
То же самое было со счедулед АПИ...Ух блеат)

Вот заебись, когда есть человек, с которым можем созвониться и которому можно рассказать о проблеме в проекте, а он подскажет, как её решить.
_____

▸ Бахайте огонёчков, если хотите
▸ Ну и комментов настрочите, если есть желание

День 17/30

Заметки про вынос "тяжёлого" содержимого в другую сущность. Ну и про автообновление зависимых сущностей.

→ Читаем, вдупляем, ставим огонёчки 🔥
____
Сегодня провёл ещё одну консультацию для девушки, которая делает приложение для своего бизнеса.
Вопросы были про количество пользователей в приложении, про регистрацию пользователей и админов, а также про то, где хранить данные юзеров: внешняя БД или на Bubble.

Если у вас тоже есть проблемы, которые не дают продвинуться в разработке — записывайтесь на консультации ко мне (650 руб./час).
Сэкономлю вам время в решении вопросов по разработке. Бабки не возьму, если не смогу помочь. Всё честно.

День 18/30

В сегодняшних заметках опшн сеты и их креативное использование.

→ Читаем статью, задаём вопросы и ставим "реакции"

День 19/30

Мама девушки периодически подкидывает мне интересные задачки на логику, внимательность и т.п.

Недавно скинула такую картинку. Где-то с 7 попытки я назвал правильный ответ))

→ Завтра опубликую ответ, а до тех пор кидайте свои варианты в комменты.
(Ответ просьба не гуглить. Честно решаем)

День 20/30

Думал сегодня выложить пост с заметками, но чёт воды много было и не наскрёб на статью. Поэтому поделюсь кратко тем, что прочёл, в этом посте:

- workflows на бэке выполняются с некоторой задержкой, поэтому иногда wf на фронте будут быстрее.
Это происходит потому что на фронте действия начинают выполняться мгновенно, время занимает только выполнение самого действия.
На бэке действия начинают выполняться с задержкой, потому что нам нужно передать сначала серверу инфу о том, что мы хотим сделать, а это занимает какое-то время. Затем сервер выполнит действие, что займёт тоже какое-то время, и передаст нам инфу с результатом, что тоже займёт время.

- Bubble изначально оптимизирован под выполнение некоторых действий на фронте и выдает мгновенный результат, несмотря на то, что изменения могут ещё выполняться на стороне сервера.
Об этом напишу в следующей части заметок. Пока просто держите в голове, что Bubble хитрый и может показывать то, чего на самом деле ещё не произошло на сервере :)

Некоторые изменения, которые следует делать на фронте:
- make changes to thing
- make changes to a list of things (если количество элементов меньше 100)

Некоторые изменения, которые следует делать на бэке:
- make changes to list of things (если элементов больше 100)
- каскадные изменения. Это когда изменение в одной сущности влечёт изменение в других сущностях.
Например, если удаляем пользователя, то нужно почистить инфу в других сущностях об этом пользователе.

Перед планированием логики, задавайте себе 2 вопроса:
1. Ожидают ли пользователи мгновенного ответа от действия?
2. Могу ли я дать мгновенный ответ.

Ну и не забываем отвлекать пользователя от долгих изменений, если не можем дать ему мгновенный ответ. Например, можно показать ему какую-то анимацию, чтобы он провтыкал в неё, пока ждёт загрузки инфы.

____
Ответ ко вчерашней задачке — 43.
Подсказки к решению:
- посмотрите внимательно на знаки
- посмотрите на количество элементов в каждой строке
- посмотрите вот что одеты человечки в каааждой строке.