​Что такое promise и какие состояния у него есть?

Это объект, представляющий завершение (или неудачу) асинхронной операции и её результат. Он позволяет ассоциировать обработчики с асинхронным действием, тем самым избавляя от необходимости использовать обратные вызовы (callback-функции). Они упрощают работу с асинхронными операциями, такими как AJAX-запросы или чтение файлов, позволяя написать код, который проще понять и поддерживать.

Состояния:
- Pending (Ожидание): Начальное состояние; асинхронная операция не завершена.
- Fulfilled (Исполнено): Операция завершена успешно, и promise возвращает результат.
- Rejected (Отклонено): Операция завершена с ошибкой, и promise возвращает причину отказа.

Пример:

let promise = new Promise(function(resolve, reject) {
    // Эмуляция асинхронной операции, например, запроса к серверу
    setTimeout(() => {
        // Условие успешного выполнения операции
        if (/* условие успеха */) {
            resolve("данные получены");
        } else {
            reject("ошибка при получении данных");
        }
    }, 1000);
});

promise.then(
    function(result) { console.log(result); }, // обработчик успеха
    function(error) { console.log(error); } // обработчик ошибки
);

Promise поддерживает цепочки вызовов (then), что позволяет организовывать асинхронный код последовательно и читабельно. Кроме того, существуют вспомогательные методы, такие как Promise.all, Promise.race, Promise.resolve, и Promise.reject, которые облегчают работу с группами асинхронных операций.

👉 @seniorFront

Animated Card Flip

Карточки свёрстаны при помощи препроцессоров Pug и Less. Логика раскрытия карточки реализована в JS.

👉 @seniorFront

​Бумажные книги по программированию — удобный инструмент или пережиток прошлого?

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

Халтурное исполнение
Также у меня есть претензии к переплёту. Недавно одна из книг в мягкой обложке распалась на отдельные страницы после первого же прочтения. Знаете такие переплёты, в которых страницы не сшиты в тетрадки, а склеены каким-то некачественным клеем? Стоит открыть такую книгу, и страницы начинают подозрительно скользить и через некоторое время вообще вываливаются из переплёта. В результате читатель получает вместо книги стопку отдельных листов. А ведь тот же Фигурнов, изданный в непростые 90-е, держался много лет.

Быстрое устаревание
Это, конечно, проблема не самих книг, а описываемых в них объектов. Уж слишком быстро они сейчас устаревают. Если раньше справочник по командам какого-нибудь MS DOS был актуален много лет, то теперь описание очередного модного фреймворка устаревает почти сразу после выхода. Поэтому сейчас я стараюсь покупать только такие книги, в которых описаны фундаментальные вещи. Например, алгоритмы, принципы и методики разработки. Такие книги не устареют ещё долгое время и не будут бесполезно занимать место и собирать пыль в книжном шкафу.

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

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

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

Но не всё так плохо. Сейчас продолжают издавать интересные книги по общим, неустаревающим темам. Жаль только, что к этим книгам применяют тот же подход, что и к мелкотемным: «Зачем стараться?»

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

👉 @seniorFront

Неклассическое чтение для руководителей: разборы и гайды по менеджменту, open source, контенту и *random topic*

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

👉 @seniorFront

bouton envoyer

Оригинальная кнопка - SVG картинка, анимированная библиотекой gsap.

👉 @seniorFront

Next Level Lightsaber

В этом видео создаётся анимация появления текста на чистом CSS. Неоновый эффект реализован при помощи теней.

👉 @seniorFront

Объяснил джуну архитектуру проекта

👉 @seniorFront

Fractal Lightning

Реализовано и анимировано на canvas и чистом JS.

👉 @seniorFront

Services section

Свёрстано на HTML и стилизовано при помощи tailwind. Эффект при наведении реализован в SCSS.

👉 @seniorFront

Spotlight Effect

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

👉 @seniorFront

ThreeJS Toys

Создано и анимировано при помощи библиотеки Three.js

👉 @seniorFront

Help the Fruit Guy

Вам дан массив строк, представляющий собой набор фруктов - свежих и испорченных. Для испорченных фруктов добавляется приставка rotten.
Создайте функцию, которая заменит испорченные фрукты свежими.

Пример:
Дано - ["apple","rottenBanana","apple"]
Результат - ["apple","banana","apple"]

👉 @seniorFront

Клиент-серверная архитектура. SA для самых маленьких

Сперва давайте обратимся к всея знаний - великому Интернету и узнаем, что за зверь такой эта клиент-серверная архитектура.

Итак, как гласит гугл:

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

Отсюда понятно, что нам надо разобраться с двумя новыми понятиями: клиент и сервер. Let's go.

👉 @seniorFront

​Назовите отличия директив v-show и v-if во Vue

Это две директивы, которые используются для условного отображения элементов в DOM. Однако они работают по-разному и имеют разные случаи использования. Рассмотрим их отличия более детально.

Основные отличия

Рендеринг в DOM:
Элемент с v-if рендерится в DOM только тогда, когда условие истинно. Если условие ложно, элемент не создаётся и удаляется из DOM.
Элемент с v-show всегда рендерится в DOM, независимо от условия. Однако, его видимость контролируется с помощью CSS-свойства display.

Переключение состояния:
v-if: Переключение между состояниями приводит к созданию или уничтожению элемента в DOM. Это может быть медленнее при частом переключении, так как каждый раз происходит перерисовка.
v-show: Переключение состояния происходит мгновенно, поскольку элемент уже присутствует в DOM, и меняется только его CSS-свойство display.

Использование в условиях:
v-if: Рекомендуется использовать, когда элемент должен быть условно добавлен или удален из DOM. Полезно, когда условие меняется редко.
v-show: Рекомендуется использовать, когда необходимо часто переключать видимость элемента, поскольку это более производительно.

Примеры:

С v-if:

<template>
  <div>
    <button @click="toggle">Toggle</button>
    <p v-if="isVisible">Этот текст отображается только если isVisible истинно</p>
  </div>
</template>

<script>
export default {
  data() {
    return {
      isVisible: true
    };
  },
  methods: {
    toggle() {
      this.isVisible = !this.isVisible;
    }
  }
};
</script>

В этом примере элемент <p> будет добавляться или удаляться из DOM при каждом нажатии на кнопку.

С v-show:

<template>
  <div>
    <button @click="toggle">Toggle</button>
    <p v-show="isVisible">Этот текст всегда присутствует в DOM, но может быть скрыт</p>
  </div>
</template>

<script>
export default {
  data() {
    return {
      isVisible: true
    };
  },
  methods: {
    toggle() {
      this.isVisible = !this.isVisible;
    }
  }
};
</script>

В этом примере элемент <p> всегда присутствует в DOM, но его видимость контролируется с помощью CSS.

👉 @seniorFront

Pixie Dust Input

При вводе текста генерируются частицы и анимируются на canvas.

👉 @seniorFront

​Типы проблемных разработчиков

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

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

Одинокие волки
Они считают себя самыми компетентными и предпочитают работать в одиночку, часто сопротивляясь совместным усилиям. Ведь зачем вам помощь другого человека, если он намного хуже вас? Обычно они участвуют в командных обсуждениях только для того, чтобы сказать всем, что они «могли бы сделать это за 3 дня». Хотя их самоуверенность иногда может быть преимуществом, она также может привести к разобщенности и потенциальному несоответствию действий целям команды. И самое главное – людям не нравится работать с одинокими волками.
Есть два способа управлять одинокими волками – принять их или заставить сотрудничать. Принятие означает, что этот человек очень ценен для вашего бизнеса, и его комфорт важнее, чем общий моральный дух команды. Не рекомендуется, но все же это возможный компромисс, если вы считаете одинокого волка суперпрофессионалом.

Обещающие слишком много
Люди, обещающие слишком много, склонны чересчур оптимистично оценивать свои возможности или время, необходимое для выполнения задач, и скрывать, когда все идет не так, как планировалось. Даже во время обновления статуса они могут сказать: «все отлично», несмотря на то, что им трудно найти решение и они сталкиваются с препятствиями – потому что все еще надеются закончить задачу в срок. Они часто не выполняют свои обещания, что приводит к разочарованию и недоверию в команде и к владельцам продукта.
Управление людьми, которые обещают слишком много включает в себя:
- установление реалистичных ожиданий вместе с членами команды;
- определение подходящего срока для проекта и разделение его на подзадачи (также вместе с членами команды);
- после этого все договариваются, сколько времени займет каждая из этих подзадач.

Ещё больше типов, а также дополнительные советы в статье.

👉 @seniorFront

Как понять, что твой мидл готов стать сеньором? Гайд для тимлида (и не только)

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

В «Лаборатории Касперского» существует устоявшийся и прозрачный пайплайн повышения мидлов — промоушен-комитет. В этой статье я подробно расскажу об этом процессе с точки зрения руководителя: от подготовки и сбора кейсов до получения кандидатом заветного грейда.

👉 @seniorFront

Pastel drawing buttons

Кнопки, стилизованные и анимированные на чистых HTML и CSS.

👉 @seniorFront

Scratch Effects

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

👉 @seniorFront

Применил паттерн "Адаптер", но что-то пошло не так

👉 @seniorFront