Minimal Clothing Catalogue

Вёрстка реализована на HTML и SCSS.

👉 @seniorFront

aria-level

aria-level помогает браузерам и вспомогательным технологиям рассказать об уровнях элементов, когда не можете передать их иерархию с помощью чистого HTML.

Пример
<span
role="heading"
aria-level="1"
>
Гайвань
</span>

Скринридеры прочтут код примерно так: «Гайвань, заголовок первого уровня».

Используйте для заголовков теги <h1>–<h6>. У них по умолчанию есть свойство aria-level. Когда по крайне важной причине верстаете кастомные заголовки, учитывайте несколько особенностей поведения aria-level.

Заголовок с ролью heading без aria-level автоматически получает второй уровень.

👉 @seniorFront

Music Player with Slider

Слайдер создан библиотекой Swiper. Логика запуска и переключения музыки реализована в JS

👉 @seniorFront

​Сколько работают программисты?

Для начала, что такое "работа"? По моему мнению, это и обдумывание задачи, и планирование, и чтение рассылок, и написание кода и рисование набросков - всё это важно.
Но под работой часто имеют в виду именно написание кода.
Мне тяжело работать больше чем 5 часов. Я могу проработать и 8, и 12, но для этого нужно иметь очень точный план работы и точное описание результата. Обычно первого нет. Реже нет второго.

По 15 часов в день работают либо профнепригодные, неспособные выполнить задачу вовремя, либо одержимые. И то и другое говорит о низком уровне организации личного времени.

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

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

Но не стоит путать работу над своими проектами и работу выходные. Это разные вещи.

👉 @seniorFront

Leap Frog Likes

Это несколько svg картинок, которые анимируются в CSS.

👉 @seniorFront

Slider with Button Wave Effect

Логика переключения слайдов реализована в JS. Анимировано библиотекой gsap.

👉 @seniorFront

Radial Octagon Menu

В этом видео с нуля создается оригинальное навигационное меню на HTML, CSS и JS.

👉 @seniorFront

👉 @seniorFront

Sticky Sections

Плавность прокрутки реализована при помощи библиотеки Lenis. Анимировано библиотекой gsap.

👉 @seniorFront

Icon Hover Effect Using

Иконки с оригинальным эффектом при наведении, созданные на HTML и CSS.

👉 @seniorFront

Creative Text Hover Effect

В этом видео автор стилизует простой текст. Изначально всем буквам кроме первой задано отрицательное значение CSS letter-spacing, из-за чего буквы скрываются.

👉 @seniorFront

animated text

Буквы создаются в JS и анимируются в CSS.

👉 @seniorFront

The Coupon Code

Создайте функцию, которая проверит, не истек ли купон.
Купон больше не действителен на следующий день после даты истечения срока действия. Все даты будут передаваться как строки в этом формате: "MONTH DATE, YEAR".

checkCoupon("123", "123", "July 9, 2015", "July 9, 2015") === true
checkCoupon("123", "123", "July 9, 2015", "July 2, 2015") === false

👉 @seniorFront

Infinite Scroll Multi-Directional Content

Реализовано на React, анимировано библиотекой gsap.

👉 @seniorFront

Как анализировать алгоритмы?

Вычислительная сложность алгоритма описывает, как выполняемый алгоритмом объём работы зависит от размера входных данных.
Обычно у алгоритмов бывает две сложности:

- временная сложность — как количество операций, которые выполняются при работе алгоритма, связано с объёмом входных данных;
- сложность по памяти — как количество памяти, которое нужно алгоритму, связано с размером входных данных.
В обоих случаях оцениваем, как связаны используемые алгоритмом ресурсы (время или память) с количеством входных данных. Может показаться, что алгоритм медленнее работает и потребляет больше памяти, когда размер входных данных большой. Это не всегда так. К примеру, скорее всего время работы функции const doNothing = (...asManyDataAsYouLike) => { } не будет зависеть от количества переданных ей аргументов. Оценка сложности этой функции — O(1). Попробуем разобраться, что это значит.

Способы оценки сложности (обозначения)
Есть несколько способов оценки сложности алгоритмов. Их основная идея – получить ограничение для функции, которая связывает размер входных данных и количество операций или размер памяти. Не стоит определять эту функцию точно, нам нужна именно оценка.

O (О-большое)
O, читается как «О», «О-большое» или «биг (big) О», описывает оценку сложности сверху. То есть максимальное количество операций, которое алгоритм может выполнить в худшем случае. В скобках после О указывают функцию, которая ограничивает сложность. Например, O(n) означает, что сложность алгоритма растёт линейно. Это означает, что время выполнения алгоритма увеличивается прямо пропорционально размеру входных данных (к примеру, есть список из 10 элементов, алгоритм займёт определённое время. Но если будет 20 элементов, то алгоритм займёт в два раза больше времени). При этом как именно линейно не важно. Давайте рассмотрим несколько примеров.

Вычислительная сложность этого алгоритма — O(n). Мы обрабатываем каждый элемент один раз. Если в нашем массиве n элементов, мы выполним тело функции reduce n раз.
const sum = (someArray) => someArray.reduce((sum, value) => sum + value, 0)

Вычислительная сложность этого алгоритма тоже будет O(n). Мы обрабатываем каждый элемент два раза. Если в нашем массиве n элементов, то выполним тело функции reduce 2 × n раз. n раз для суммирования и n раз для произведения. Это описывает формула O(k × n) = O(n). В нашем случае коэффициент не имеет значения, так как он не зависит от размера входных данных.
const sumAndProd = (someArray) => {
const sum = (someArray) => someArray.reduce((sum, value) => sum + value, 0)
const prod = (someArray) => someArray.reduce((prod, value) => prod * value, 1)
return sum * prod
}

👉 @seniorFront

Collapsible Timeline

Свёрстано на HTML и CSS. Логика раскрытия элементов меню реализована в JS.

👉 @seniorFront

​Путь к мастерству в программировании

Привет, кодер! Неважно, новичок ли ты, отлаживающий свою первую программу «Hello World», или опытный инженер — у каждого из нас всегда есть возможность улучшить свои навыки. Эта статья для тех, кто хочет поднять свои существующие скиллы на новый уровень.

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

- «Чистый код» Роберта Мартина. Эта библия качества кода должна быть на полке каждого разработчика. Дядюшка Боб проповедует искусство создания чистого, читаемого кода в этой и многих других своих работах.

- «Прагматичный программист» Ханта и Томаса. Этот классический том наполнен практической мудростью по программированию, советами по избеганию запутанного кода, привычками для выработки и отношением, которое следует принять.

- «Практическое объектно‑ориентированное проектирование на Ruby» от Санди Метц. Эта книга предлагает бесценные идеи в понимании написания модульного, понятного объектно‑ориентированного кода, применимого к любому ОО языку. В ней будут советы о создании умных абстракций с объектами и классами, минимизации зависимостей между компонентами и избегании ужасных «монстр‑классов» из тысяч строк кода.

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

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

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

Такие сайты как LeetCode, HackerRank и Codewars предлагают огромные каталоги задач по программированию и алгоритмических головоломок для решения.

👉 @seniorFront

​Почему конфликтуют тестировщики и разработчики, и как этого избежать

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

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

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

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

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

Корень конфликта
Таким образом, мы обнажили корень конфликта — разные цели! Когда у людей разные цели, как их не объединяй, они всё равно будут идти каждый своей дорогой, по итогу – в разные стороны.

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

👉 @seniorFront

Responsive Portfolio

Это полноценная страница-портфолио, свёрстанная в стиле macOS на HTML и CSS.

👉 @seniorFront