Что больше всего недооценивают разработчики?

Soft skill-ы

Это при том, что они определяют успешность разработчика гораздо больше, чем Hard skill-ы (об этом отдельный постик)

И сегодня расскажу вам основные Soft skills, которые ожидают от Senior разработчика (го в карусель 🎠)

Солнечной качалки 🦾

#itkachalka #itkmidtosenior #davidshekunts #davidshekunts_it

https://www.youtube.com/watch?v=Eu2mrgbXytE

- Новый Docker for Mac с поддержкой Apple M1
-​ Локальный k8s
-​ Сравнение minikube, k3s, kind, microk8s
-​ Тизер курса
-​ Redux Toolbox

Я делаю эти видосы в первую очередь для инсты (там удобно их размещать), но вопрос: вам было бы интересно, если я буду здесь выкладывать такие видосы?

Если да, пишите комменты

Всем доброй качалочки 💪

"Вот научился я кодить, вот стал Middle разрабом, а дальше то что? Куда? В петлю?"

(для всех, кто не подписан на мой инстаграм посты с опозданием, а тем кто подписан увидит сегодня новый пост)

Предоставляю вам немного моего ИМХО на тему Hard Skill-ов старшего разработчика

Доброй вечерней качалочки 🦾

#itkachalka #itkmidtosenior #davidshekunts #davidshekunts_it

Где проходит граница между задачами Middle и Senior разработчика?

(для всех, кто не подписан на мой инстаграм)

Пока Middle в большей степени "кодит функционал", у Senior появляются более "тонкие" задачи, которые относятся к тому: "что и как мы будем кодить, а главное, как мы будем все это чинить?"

Остальное в карусели 🎠

Хорошей к прокачки 💪

#itkachalka #itkevolution #davidshekunts #davidshekunts_it

😞 Что делать, когда надоел кодинг 😞

(для всех, кто не подписан на мой инстаграм)

Я люблю кодить, но когда этот процесс растягивается на 3-5 лет... В один момент начинаешь задумываться, что пора бы попробовать что-то новенькое

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

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

Надеюсь полезен вам 😉

#itkachalka #itkevolution #davidshekunts #davidshekunts_it

🔥 Воркшоп через полтора часа 🔥

Напоминалочка

Кто сможет, всем буду рад 🥰

😩 Устал быть мидлом? Не знаешь куда, а главное как развиваться? А может вообще надоел кодинг? 😩

Я вас отлично понимаю, я тоже был в ситуации этого распутья, НО мне сильно повезло и за последние 7 лет я сумел поработать в куче разных ролей и хочу рассказать вам: как и куда может расти middle разработчик (даже если не хочется больше кодить)

Завтра воскресенье 28.03 в 19:00 я проведу воркшоп, в котором расскажу про пути "🦍 Эволюции разработчика 👨‍💻" (по мотивам постов #evolution)

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

Воркшоп пройдет в zoom (ссылку кину завтра в канал), потому что мне важно иметь возможность дискутировать с вами и вживую отвечать на все вопросы

Добавляйте событие в календарь и ждите ссылочки, всем качалки 🦾

все на rxjs

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

В упрощенном варианте все базируется на трех сущностях
funnel - воронка
stage - этап
deal - сделка

Рассмотрим 2 структуры (псевдо разметка). И в качестве примера задача: меняется значение color у сущности stage, информация об этом пришла по сокетам

1 вариант структуры

funnel$: Observable<T> = {
name: T,
...,
stages: T[] [{
name: T,
color: T,
...,
deals: T[] [{
name: T,
...
}]
}
}
в случае изменения цвета, находим stage по id, изменяем значение color, затем $funnel.next($funnel.value)
данные на клиенте обновились.

2 вариант

funnel$: Observable<T> = {
name$: Observable<T>,
...,
stages$: Observable<T[]> [{
name$: Observable<T>,
color$: Observable<T>,
...,
deals$: Observable<T[]> [{
name$: Observable<>,
...
}]
}
}

в случае изменения цвета, находим stage по id, изменяем значение color, затем $funnel.value.stages$.value[index].value.$color.next(color);
данные на клиенте тоже обновились

Вопросы
1) как вообще обычно делают такие штуки, может какой-то из способов вообще не приемлем?
2) на мой взгляд у каждого способа есть свои плюсы и минусы. Глобально в первой проще намного работать с данными внутри компонент, во втором намного меньше рендерятся компоненты, завязанные на данных.
3) подозреваю, что выбор зависит от бизнес-задач, как часто будут приходить сообщения об изменении данных.

💬 Вопросы от подписчиков 💬

Прекрасная задачка на тему структуры менеджера состояний на фронте

Не стесняйтесь писть и вы свои вопросы мне в ЛС (@davidshekunts) с удовольствием отвечу

Попробую ответить, если правильно понял

Для начала определим возможные проблемы:

1. Сложность написания кода
2. Зависания из-за ререндеринга
3. Зависания из-за обновления громадных сущностей

3 – только в том случае, если сущность очень объемная (сотни полей). Эту проблему можно обойти тем, что часть обхемных атрибутов (например связи) выносить в отдельное место и связывать по id (как нормализация в БД) или превращать тоже в Observable (то есть не все поля, а только это)

2 – в первом случае, у вас будет одна большая подписка, в которую будет падать полный объект и если не разрулить на уровне компонентова понимание "(не)изменилось" будет перерисовывать вееесь элемент и все его дочерние компоненты. Тут соответственно или проверка на изменение или, если компонент небольшой, забить хрен и не париться

1 – первый вариант намного проще

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

Далее начинаете писать сравнение на изменение в элементах

Потом превращаете какие-то отдельные атрибуты сущности в Observable (большими кусками) и делаете на них отдельную подписку