CSS animated SVG

Это SVG картинка, стилизованная и анимированная в SCSS.

👉 @seniorFront

Неразрешимые проблемы программирования

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

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

Сейчас общепризнанно, что нестандартные задачки для этого не сильно подходят: когда-то их давали в Microsoft, но потом перестали. Иногда их дают в других компаниях. Мы научились более-менее отвечать на вопросы, почему люки круглые, или сколько заправок в Нью-Йорке, но, похоже, они не помогают работодателю оценить программиста.

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

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

Затем вам дают проект — из тех, что мы называем legacy. Триста человеко-лет — десять лет и тридцать программистов. Часть из них сидит сейчас рядом с вами, но другая часть давно уволилась. Ваша задача — разобраться в проекте как можно быстрее.

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

Код-ревью
Здесь прекрасно всё, даже трудно выбрать, с чего начать. Да, вы и сами всё знаете.

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

Когда нас называют идиотами, мы конечно, возмущаемся. А когда мы называем идиотами — нет.

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

👉 @seniorFront

​Хороший парень, плохой код: доброта дороже денег?

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

Робин Гуд наоборот
Представьте, что вы — суперпонимающий, эмпатичный тимлид. У вас возникает соблазн оставить этого неэффективного разработчика просто потому, что он хороший человек. Но вот в чем загвоздка: по сути, вы будете платить ему из денег, заработанных его коллегами, теми, кто действительно выкладывается, фигачит овертаймы и вносит свой вклад в успех проекта. Такой вот странный сценарий Робина Гуда, только он отбирает у работящих, чтобы отдать... ну, не очень работящим.

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

Если же это не помогло, вариантов два:
Рефакторинг. Скорректировать зарплату разработчика в соответствии с его реальным вкладом. Это может показаться жестким, но это способ сохранить справедливость и обеспечить всем соответствующее вознаграждение.

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

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

👉 @seniorFront

Squidematics

Реализовано на canvas и JS без использования библиотек для создания анимаций.

👉 @seniorFront

Awesome Cursor Animation on Mousemove

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

👉 @seniorFront

Когда решил запустить программу, которую написал без тестов:

👉 @seniorFront

Rotating 3D Slider

Логика поворота слайдера реализована в JS. Стилизовано в SCSS.

👉 @seniorFront

animated icons

Это SVG картинки, анимируемые в SCSS при наведении.

👉 @seniorFront

Full Page Scroll Progress Indicator

В этом видео создаётся индикатор прокрутки страницы на CSS и JS.

👉 @seniorFront

Starry Campsite

Вся сцена реализована с использованием возможностей препроцессоров Pug и SCSS.

👉 @seniorFront

Currying functions: multiply all elements in an array

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

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

Вы не должны изменять исходный массив.

Пример:
multiplyAll([1, 2, 3])(2) = [2, 4, 6];

👉 @seniorFront

Don't Repeat Yourself: Как правильно использовать принцип DRY в разработке ПО

Принцип “Не повторяйся” (Don't Repeat Yourself, или DRY), то есть избегай дублирования кода, часто относят к обязательным практикам в программировании. Однако в реальности часто можно увидеть, как в общем коде оказываются концептуально разные блоки, которые похожи только по внешним параметрам. Это неминуемо приводит к ухудшению кода и появлению "костылей", без которых он не работает. Именно поэтому слепое следование принципу DRY не всегда целесообразно! В этой статье рассказывается про типичные ошибки при использовании этого правила и способы их избежать.

👉 @seniorFront

.with()

Метод with() изменяет значение одного из элементов массива и возвращает новый массив, без изменения исходного массива.

Пример
Изменим элемент 'white' на 'blue':
const colors = ['red', 'green', 'white']
const newColors = colors.with(2, 'blue')
console.log(newColors)
// ['red', 'green', 'blue']

// Исходный массив остался прежним
console.log(colors)
// ['red', 'green', 'white']

Как пишется
Array.with() принимает два аргумента:

1. индекс элемента, который нужно изменить;
2. новое значение изменяемого элемента.

Индекс элемента может быть:
- положительный — для доступа к элементам от начала массива;
- отрицательный — для доступа к элементам с конца массива. Например, -1 — индекс последнего элемента, -2 — предпоследнего и т. д.
Array.with() возвращает массив с изменённым элементом.

Вызов with() без аргументов, не приведёт к ошибке. Это равнозначно вызову with(0, undefined):

👉 @seniorFront

Amazing Product transition

Создано и анимировано на HTML и CSS.

👉 @seniorFront

​Куда подевались ваши манеры? Коллеги в IT

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

Первоначальное знакомство очень важно
Была компания в которую мне очень хотелось попасть, но разговоры с HR-менеджером постепенно и по-этапно отталкивали меня от этого решения. Все начинается с достаточно долгих ответов на вопросы с зазором от нескольких часов, до нескольких дней и тут возникает вообще мысль, а нужен ли я им как работник при отсутствии какого-то интереса к себе?

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

Будь почтителен со своими родителями, родственниками и с менеджером Иваном из своей компании
Пришла ко мне очередная бизнес-задача, уже с подготовленной документацией и согласованным архитектурным решением от менеджеров. Казалось бы, просто взял, реализовал, протестировал и выпустил в релиз, но менеджер Иван решил продемонстрировать свою важность, и релиз затянулся на неопределенный срок.
Всё началось с согласования мердж-реквеста в релизную ветку. На просьбы посмотреть и согласовать изначально был игнор, потому что Иван был очень занят согласованием других мердж-реквестов.
Заказчики уже ожидают функционала на продакшене, а я все еще не могу получить согласование от нашего менеджера. Это заставляет меня поднять вопрос на ретроспективе: почему этот менеджер взял на себя обязанности по согласованию всех задач в релизе и не может выполнять свою работу вовремя? Возможно, он вообще лишнее звено в этой бюрократической цепи. Другие разработчики тоже сообщают о таких проблемах, и наш тимлид решает провести разговор с Иваном и ускорить процесс.
Результатом данного разговора стало то, что Иван отказывается согласовывать данные доработки, аргументируя тем, что ему не устраивает архитектурное решение, хотя ранее он уже его согласовывал. Он указывает мне, что я должен посмотреть его расписание в календаре и назначить встречу с моим тимлидом и аналитиком, причем я не упоминаюсь в этой встрече. И разговор проходит в тоне, как-будто я секретарша, а он мой начальник, хотя в юридической структуре мой руководитель, мой тимлид.

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

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

👉 @seniorFront

Увольнять нельзя удерживать

В мире ИТ вполне обычное дело, когда сотрудник компании получает выгодное предложение от компании-конкурента. В целом, это распространенная практика, ведь всем необходимы специалисты с опытом и развитыми навыками и компетенциями. А где же их развивать, как не в компаниях, откуда потом сотрудника можно забрать.

В этой статье рассматривается такая ситуация с точки зрен6ия менеджера. Будет полезно прочитать тем, кто задумывается о принятии контроффера.

👉 @seniorFront

Smooth 3d perspective slider

Свёрстано при помощи препроцессоров Pug и SCSS. Функционал слайдера и логика поворота карточки реализована на чистом JS.

👉 @seniorFront

Light & Shadow Text Shadow Animation

В этом видео создается тень текста, при помощи CSS text-shadow, затем в JS изменяются параметры этой тени.

👉 @seniorFront

👉 @seniorFront

Proximity Glow Cards

Настройки стилей карточек реализованы при помощи библиотеки dat.gui. Стилизовано и анимировано в CSS.

👉 @seniorFront