В дополнение ко вчерашнему стриму рекомендую посмотреть статью про стратегии репликации и объединения данных
Часть идей могут использоваться при объединении пользовательских стейтов на стороне бэкенда

Привет, друзья! Сегодня мы поговорим о личной мотивации.

Как часто вы чувствуете, что у вас нет сил и желания продолжать работу над проектом? Как часто вы задаетесь вопросом, зачем все это нужно?

В такие моменты очень важно найти внутреннюю мотивацию. Что вас вдохновляет? Что заставляет вас двигаться вперед?

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

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

И конечно же, не стоит забывать о команде. Работа в коллективе - это еще один источник мотивации. Когда вы работаете вместе с единомышленниками, вы можете обмениваться опытом, делиться идеями и находить новые решения.

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

Спасибо за внимание!

P.s. угадай какой gpt это написал и какой примерно был промпт! )

Вас тоже взбудоражила новость о том, что сломался DNSSEC?
Лично меня нет, я опять все проспал и узнал все постфактум.
Помните, здоровый сон бережёт вашу нервную систему!
https://habr.com/ru/news/790188/

Субботний стрим 03.02 10:00

Начинаю сбор вопросов на стрим, напоминаю, что у нас будет четыре секции:

- Зачем это надо? (ЗЭН)
- анализирую это (разбираем этапы работы javascript runtime)
- Сплетни нашего ютуба
- Донаты решают

В комментарии к этому посту скиньте вопросы на ЗЭН, они должны касаться АйТи.

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

Залетайте на стрим поговорим про организацию процессов внутри команды.

Если вы разогнались и хотите еще какой-нибудь стрим посмотреть, то прямо сейчас стримит HollyJS ) - https://www.youtube.com/watch?v=GJOVUGL5v0I

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

Разделение ответственности в UI компонентах

Привет, на связи @devmargooo и сегодня я хотела бы рассказать свои мысли насчет разделения ответственности в UI компонентах. В своей “Чистой архитектуре” Р. Мартин пишет, что принцип единственной ответственности (SRP) является следствием закона Конвея и определяет, что лучшей является такая структура программной системы, при котором каждый модуль может быть изменен только вследствие удовлетворения интересов одного единственного актора. На мой взгляд, при разработке библиотеки UI компонентов удобно использовать схожий принцип, который можно сформулировать следующим образом: каждая логическая зона UI может менять свое состояние вследствие изменения конфигурации одного и только одного компонента в коде. Под “логической зоной” я пониманию небольшой кусочек UI, который несет полезную нагрузку для пользователя и может находится в разных состояниях. Разберем на примере текстового инпута. В нем я выделяю следующие логические зоны: поле ввода (возможные состояния - пустое, непустое, задизабленное, с ошибкой), крестик возле инпута (возможные состояния - присутствует, отсутствует), иконка возле поля ввода, подпись под полем ввода. Библиотеки UI компонентов часто разрабатывают таким образом, что в них есть “самые базовые компоненты” (например, Input), и компоненты, которые построены на основе этих “самых базовых компонентов” (ErrorInput, LabelInput, IconInput etc) по принципу “матрешки”. Таким образом, нам нужно следить, чтобы в этой иерархии изменять состояние каждой логической зоны мог только компонент! Например, возможность рендера иконки рядом с полем ввода должен иметь только один компонент - или Input, или IconInput, и тд. Рассмотрим следующий пример реализации Input и ErrorInput на React:

interface InputProps {
  value: string;
  setValue: (newValue: string) => void;
  icon?:string;
}

const Input = ({value, setValue, icon}:InputProps) => (
  <div className="input">
    {icon && <div className="icon">{icon}</div>}
    <input type="text" value={value} onChange={(e) => setValue(e.target.value)}/>
  </div>
)

interface ErrorInputProps extends InputProps {
  is_error?: boolean;
}

const ErrorInput = (props:ErrorInputProps) => (
  <div className="error_input">
    {props.is_error && <div className="error_icon">X</div>}
    <Input {...props}/>
  </div>
)

При таком подходе возможна ситуация, когда в ErrorInput будут одновременно переданы пропсы is_error и icon и в одной и той же логической зоне иконки будет отрендерено сразу две иконки, одна поверх другой. Следовательно,важно следить за тем, чтобы логическую зону иконки мог изменять только один компонент - в нашем случае это компонент Input. В своей практике я видела достаточно много багов, попавших на продакшн вследствие нарушения этого принципа.

V набор NarisApp
Начинаю набор в V сезон. Информацию о проекте и порядке участия можно посмотреть здесь - https://s0er.ru/documents/article/6008

Коротко: NarisApp это OpenSource приложение которое мы делаем с командой  SOER.PRO, подать заявку на участие может каждый желающий. Каждый раз мы набираем 30 человек, из которых до конца доходит 5-7 человек. Все очень весело и хардкорно.

В работе над новыми проектами есть свой вайб.

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

Очень хочется, чтобы инженеров, которые понимают о чем я говорю, становилось больше. Ведь в этом и состоит кайф работы в профессии. Иначе смысл протирать штаны, дожидаясь пятницы и выходных?

Залетайте на стрим. Сегодня будет просто разговор о том как прошла неделя, какие новости, какие интересные вещи делали. Ответы на вопросы.

Со следующего стрима хочу в таком виде показывать бой между "Ангуляром" и "Реактом". Но такой вопрос, кто-нибудь хочет присоединиться и попилить фичи для этого проекта?
Проект на Unity там можно сделать кучу улучшений - допилить механику, сделать тени и т.д.

... каким должен быть канал по архитектуре.

Альтернативный способ попасть в Соер Клуб - получить личное приглашение.

Я создал новую группу Soer Open Source (SOS) для тех кто делает свои проекты или хочет принять участие в чьем-то проекте. Цель группы вместе писать и обсуждать код.

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

Если нравится писать код или есть свои проекты - https://t.iss.one/+F0tfJEbG_H8xNWEy

Отлично сказано про выгорание

«Истощение — это когда вы дошли до точки и больше не можете идти дальше. Выгорание же означает, что вы дошли до точки и всё равно заставляете себя двигаться вперед».