День 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.
Подсказки к решению:
- посмотрите внимательно на знаки
- посмотрите на количество элементов в каждой строке
- посмотрите вот что одеты человечки в каааждой строке.

День 21/30

Заметки. Часть 14. Ответ на действия пользователя.

→ Ставьте "реакции" на пост, если был полезным.
___
Чёт подзадолбался писать. Как закончится марафон, устрою себе выходной без гаджетов. А лучше два.

День 22/30

Сегодня насыщенные практическими советами заметки по оптимизации workflow.

→ Залетаем, читаем, оставляем комментарии и ставим лайки.

День 23/30

Don't repeat yourself, ребятки. Сегодня статья коснулась программистского термина "Не повторяйся".
Тут про custom event и про reusable element.

→ Читаем, применяем, реакцию на пост ставим

День 24/30

Спасибо за реакции на постах, ребят!

Для меня важно видеть эти реакции по двум причинам:
Первая. Реакциями вы показываете ваш интерес к затрагиваемой теме.
Вторая. Мне просто приятно видеть "пальцы вверх" на моих постах. Это человеческая потребность в признании и в чувстве значимости.

______

Сегодня поделюсь моими планами в разработке на ближайшее время и расскажу про канал:

🔻 Канал

Хотел бы начать с того, что вас уже 250 на канале. Меньше чем за месяц вас стало на 120 человек больше (!). Спасибо вам!

Я бы хотел для себя сделать подробную статистику, чтобы понять, кто именно меня читает.
Поэтому прошу вас пройти этот опрос. Он небольшой — всего 4 вопроса. Время прохождения 5 минут.

Этот опрос поможет понять, кто меня читает, и послужит фильтром от неактивной аудитории.

На прохождение опроса есть 14 дней. 20 ноября мой бот автоматически уберёт тех, кто не прошёл опрос.

Мне важно видеть среди подписчиков тех, кому интересно то, о чём пишу. Мёртвые души на канале не хочу видеть. Надеюсь, на ваше понимание.

🔻 Разработка.

В конце ноября будет созвон по школе21 от Сбера — скажут, какие доки нести и дату начала интенсива. Зимой, собственно, будет сам интенсив. Думаю, пройду его, и меня отберут в основное обучение, которое продлится 1.5-3 года.

По заказам: закончил работу над софтом для Дзена. Сейчас свободен и открыт к новым заказам.
Работаю либо с оплатой за проект по предоплате 50%, либо по почасовой оплате с предоплатой за первые 10 часов из расчёта 1500 рублей / час.

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

Почти дочитал книгу по производительности. Осталось 20 страниц. Как с ней закончу, займусь записью обучающего курса по Bubble.

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

Вот такие новости.
Ещё раз ссылочка на опрос. Через 2 недели ботик всех, кто не прошёл, уберёт.

День 25/30

Чёт вы навалили там пальцев вниз и даже шоколадного поставили.
Пишите, что вас не устраивает. Обсудим.
___

Сегодня заметки по бэку: триггеры и циклы.

→ Читаем, ставим "реакции" на пост, если нравится контент.
→ Если не нравится, то пишите, что хотите видеть на канале.

Ребят, я вас услышал. Исключать никого не буду.

Попрошу только ещё раз пройти опрос, чтобы мог понять, кто читает мой канал и на кого ориентироваться при написании постов.