​Почему TypeScript считает compatible тип функции с меньшим количеством аргументов?

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

Пример:

 type User = { name: string; };
 type Admin = { name: string; adminRights: boolean; };

 function logUser(user: User) {
   console.log(user.name);
 }

 const admin: Admin = { name: 'Alice', adminRights: true };

 logUser(admin); // TypeScript разрешит передачу admin в logUser

Преимущества:
1. Это предоставляет бóльшую гибкость в работе с функциями.
2. При правильном использовании позволяет избежать избыточной информации в определении функций.

Недостатки:
1. Может потенциально вызвать ошибки в ситуациях, когда поддерживается передача дополнительных аргументов без явного указания этого в сигнатуре функции.
2. Может показаться непривычным для разработчиков, привыкших к более строгой типизации в других языках.

👉 @seniorFront

Day & Night Toggle

Внутри переключателя SVG картинка, стилизованная в CSS. Логика изменения фона реализована в JS.

👉 @seniorFront

​Экстремальные практики программирования

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

Рассмотрим некоторые практики:

Разработка через тестирование
Эта практика подразумевает, что разработчики сначала пишут тесты, а потом под эти тесты пишется программное обеспечение. Наличие автотестов, которые запускают после каждого изменения кода, — это критически важный момент. Без этого уже тяжело представить взаимодействие с большой кодовой базой.

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

«Заказчик всегда рядом»
Классическая модель работы выглядит так: заказчик ставит задачу, бизнес-аналитики собирают требования, исполнители реализуют проект и приносят результат на утверждение. Часто это не самая удачная стратегия.
Принцип «заказчик всегда рядом» подразумевает, что команда контактирует с заказчиком супермаленькими интервалами, показывая ему процесс разработки в мелочах. Это помогает вовремя всё подправить и избежать ситуации, когда при сдаче проекта оказывается, что требования поняли некорректно и принесли не тот результат.

Парное программирование
Вместо того, чтобы разработчик работал в одиночку, а потом показывал результат коллегам или продакт-оунеру, процесс построен по аналогии с гонками: когда есть драйвер и штурман.

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

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

👉 @seniorFront

Star Trails with options

Звёзды генерируются и анимируются на чистом JS.

👉 @seniorFront

Cube Effect Slider

Куб сделан при помощи библиотеки Swiper. Частицы на фоне генерируются библиотекой tsparticles.

👉 @seniorFront

Cursor Follow Navigation Menu

В этом видео создаётся оригинальный эффект при наведении на меню при помощи CSS и JS.

👉 @seniorFront

👉 @seniorFront

Pizza Toggles

Оригинальные переключатели, реализованные с использованием возможностей препроцессоров Haml и SCSS.

👉 @seniorFront

Dots & Ring Loader

Оригинальный загрузчик, реализованный с использованием препроцессоров Pug и SCSS.

👉 @seniorFront

Animated Glowing Gradient Border

В этом видео создаётся светящаяся анимированная граница на CSS.

👉 @seniorFront

Keyboard pressing text effect

Создано и анимировано на чистом CSS.

👉 @seniorFront

Как получить реальный опыт во фронтенд-разработке за 7 дней?

А именно:

- Сверстать веб-сайт на HTML + CSS;
- Реализовать функционал на JavaScript;
- Пощупать фронтенд-фреймворк Angular;
- Подключить Backend и загрузить сайт на хостинг.

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

Такой опыт можно получить на бесплатном практикуме от Айтилогии с поддержкой от опытных разработчиков на каждом этапе.

👉 Приходи на бесплатное обучение и зови с собой друзей

Бонусом получишь гайд для поиска работы и заказов на фронтенд-разработку.

Valid HK Phone Number

В Гонконге действительный телефонный номер имеет формат xxxx xxxx, где x - десятичная цифра (0-9). Определите две функции isValidHKPhoneNumber и hasValidHKPhoneNumber, которые возвращают, является ли заданная строка валидным номером телефона и содержит ли она валидный номер телефона соответственно (т.е. значения true/false).

Пример:
isValidHKPhoneNumber("1234 5678") = true

👉 @seniorFront

Radios With Sliding Focus

Реализовано без использования JS.

👉 @seniorFront

Array.toLocaleString()

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

Для элементов массива, являющихся null или undefined, возвращается пустая строка.

Пример
Получим строку из массива с учётом локализации de-DE (немецкий язык и региональные стандарты чисел и дат Германии):

const array = [null, 50, 15000, new Date('2007-08-10')]
const arrayStr = array.toLocaleString('de-DE')
console.log(arrayStr)
// 50,15.000,10.8.2007, 03:00:00

Получим строку из того же массива с учётом локализации en-US (английский язык и региональные стандарты чисел и дат США) и указанием часового пояса:

 const array = [null, 50, 15000, new Date('2007-08-10')]
 const arrayStr = array.toLocaleString('en-US', {timeZone: 'Europe/Amsterdam'})
 console.log(arrayStr)

// 50,15,000,8/10/2007, 2:00:00 AM

👉 @seniorFront

Custom Cursor Effect

Реализовано на HTML, CSS и чистом JS.

👉 @seniorFront

​«Относитесь к собеседованию, как к свиданию» — 5 причин, почему разработчики не могут найти работу

1. «Мне не отвечают, когда откликаюсь на вакансию»
Когда я последний раз менял место работы, сосчитал личную статистику: конверсия с этапа откликов на этап приглашения на собеседование составила около 10%. Таким образом, откликнувшись на вакансию в 10 компаний, вы, скорее всего, получите 1 приглашение на собес. На удивление, конверсия с этапа пройденных собеседований на этап предложения о работе составила также около 10%. То есть на 10 собеседований пришёл 1 job offer.

2. «У меня пустое резюме»
Я столкнулся с этим, когда начал проводить технические интервью с кандидатами. Пустое резюме может быть по объёму, когда есть всего 3-4 цепляющих внимание строчки, и по смыслу, когда строчек много, но все они ни о чём.
В первом случае проблема в том, что разработчик, имея крутой опыт, сомневается, стоит ли указывать его в резюме (например, свои pet-проекты), либо вовсе не умеет описывать обязанности на предыдущем месте работы. И всю информацию получается вытянуть только на техническом интервью.
Во втором — описывает опыт обтекаемыми фразами, по которым сложно понять уровень профессионализма. Например, «разрабатывал внутренние/внешние проекты компании». Сразу возникает вопрос: что это за проекты?

3. «У меня недостаточно знаний для данной вакансии»
В вакансиях довольно часто пишут требования с запасом. Если у кандидата неполный набор хард-скиллов, но он умеет думать — работодатель чаще всего уступит и пойдёт навстречу. На мой взгляд, лучше честно заявить, что вы не работали с какой-то технологией, но готовы попробовать, когда выйдете на работу. Работодатель ищет себе не робота, который может в теорию, а человека, у которого хорошие хард-скиллы и неплохие софты.

4. «Я испытываю стресс до начала и во время собеседования»
Самая частая проблема, которая бывает при поиске работы. Многие относятся к собеседованию как к экзамену, но вы же не в универе🙂. Недавно я услышал крутое объяснение термина «собеседование» — это свидание между будущим сотрудником и будущим работодателем. Вы же, когда ходите на свидания, не ведёте себя как на экзамене? Да, волнуетесь, но, скорее, из-за того, что переживаете — вдруг вам не понравится. С собеседованиями аналогичная ситуация — на них надо ходить с мыслью, что вы лишь знакомитесь с компанией/командой/будущим руководителем.

5. «Я боюсь ошибиться/затупить на собеседовании»
Обычно, когда кандидат допускает одну ошибку, то из-за волнения делает вторую, третью и так далее. Однако не забывайте, что и со стороны работодателя могут ошибиться во время технического интервью. Был на моей практике такой случай. Стандарт немного поменялся, и в JavaScript стало 8 типов данных, а не 6, как раньше. Кандидат знал об этом, а я не успел зафиксировать для себя изменения. Тогда получилось, что я ошибся перед кандидатом, а не он передо мной.

👉 @seniorFront

Procedural Birb

Картинки генерируются и анимируются библиотекой svg.js. Панель настроек создана при помощи библиотеки dat.gui.

👉 @seniorFront

Glow slider

Это input type="range", стилизованный в CSS.

👉 @seniorFront