Counting Duplicates

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

Пример:

"abcde" -> 0 # no characters repeats more than once
"aabbcde" -> 2 # 'a' and 'b'
"aabBcde" -> 2 # 'a' occurs twice and 'b' twice (`b` and `B`)
"indivisibility" -> 1 # 'i' occurs six times
"Indivisibilities" -> 2 # 'i' occurs seven times and 's' occurs twice
"aA11" -> 2 # 'a' and '1'
"ABBA" -> 2 # 'A' and 'B' each occur twice

Я делаю рефакторинг ежечасно» или как за пять минут улучшить приложение

История этой статьи началась с того, что я вспомнил о довольно известном высказывании Мартина Фаулера, автора книг и статей по архитектуре ПО, которое нередко вызывает недопонимание (во всяком случае так было у меня) — «Я делаю рефакторинг ежечасно». Первая мысль, которая логично возникает после этого высказывания — уважаемый публицист просто лукавит. Вторая — что, наверное, кроме рефакторинга он в своей жизни ничем больше не занимается. Но так ли это?

👉 @seniorFront

😡 Устал от нудных уроков на YouTube, где половина — вода?

Хватит это терпеть) Автор канала Формошлёп убрал воду и оставил только суть:

➧ Мини-гайды по HTML, CSS и JavaScript, которые легко читать и сразу применять.
➧ Шпаргалки, лайфхаки и полезные советы с ноткой юмора.
➧ Всё чётко, лаконично и по делу.

Неважно, новичок ты или фронтендер на опыте — у нас всегда найдётся что-то полезное!

Присоединяйся: @frontbox будем вместе шлёпать формы и красить кнопки)

​Зачем придумали async/await?

Ключевой целью введения async/await в JavaScript было упростить написание и чтение асинхронного кода, сделать его более линейным и похожим на синхронный.

Улучшение читаемости кода
Асинхронный код, написанный с использованием коллбеков или промисов, может быть трудным для чтения и понимания, особенно когда имеется несколько вложенных асинхронных операций. async/await делает асинхронный код более линейным, что упрощает его понимание.

Пример с промисами:

function fetchData() {
  return new Promise((resolve) => {
    setTimeout(() => {
      resolve("some data");
    }, 1000);
  });
}

fetchData().then((data) => {
  console.log(data);
}).catch((error) => {
  console.error(error);
});

Пример с async/await:

async function fetchData() {
  return new Promise((resolve) => {
    setTimeout(() => {
      resolve("some data");
    }, 1000);
  });
}

async function main() {
  try {
    const data = await fetchData();
    console.log(data);
  } catch (error) {
    console.error(error);
  }
}

main();

Избегание "ада коллбеков"
Когда асинхронные операции вложены друг в друга, код становится трудным для чтения и сопровождения. Это называется "адом коллбеков" (callback hell). async/await позволяет писать асинхронный код последовательно, без вложенности.

Пример с промисами:

getData((data) => {
  processData(data, (processedData) => {
    saveData(processedData, (result) => {
      console.log(result);
    });
  });
});

Пример с async/await:

async function main() {
  try {
    const data = await getData();
    const processedData = await processData(data);
    const result = await saveData(processedData);
    console.log(result);
  } catch (error) {
    console.error(error);
  }
}

main();

Снижение вероятности ошибок
Когда используется async/await, ошибки могут быть обработаны с использованием привычного try/catch блока, что снижает вероятность пропуска ошибок.

Пример с промисами:

fetchData().then((data) => {
  return processData(data);
}).then((processedData) => {
  return saveData(processedData);
}).catch((error) => {
  console.error(error);
});

Пример с async/await:

async function main() {
  try {
    const data = await fetchData();
    const processedData = await processData(data);
    const result = await saveData(processedData);
    console.log(result);
  } catch (error) {
    console.error(error);
  }
}

main();

👉 @seniorFront

Secret Project

Концепт приложения с множеством функций на HTML, CSS и JS

👉 @seniorFront

​Как использовать японские подходы в IT. Часть 1: петля за петлей

В этом цикле статей мы поговорим о том, как устроены процессы «у них», почему они не всегда работают «у нас» и как их адаптировать для IT. Здесь не будет много душных цитат и ссылок на книги типа «Дао Toyota». Только кристаллизованный личный опыт: ошибки, наблюдения и выводы одного русского парня.

Разберись в корне проблемы (root cause, 5 why)
Как бы сделали на производстве раньше: связали нить и стали ткать дальше, будто ничего не было. Этот процесс уже стал привычным, порождая проблемы с возвратом. Проблема привела к простой мысли: если нить рвется, то станок надо остановить и сделать так, чтобы она не рвалась.

Если что-то идет не так — остановись (дзидока)
Нить — это совокупность волокон, сплетенных между собой. Мы можем не заметить, если одно из волокон надорвется, но нить станет более хрупкой. Что говорить о том, когда рвется сама нить.

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

Но как сделать, чтобы нить не рвалась? Усовершенствовать станок!

Постоянно совершенствуй (kaizen)
Тоёда-сан шел по циклу Деминга:
- Замечал проблему.
- Придумывал решение.
- Записывал, что идет не так.
- Менял это.
Однако он не мог знать этого, так как до разработки цикла оставались еще десятки лет. Годы жизни Сакити Тоёда — 1867–1930 годы.

Обменивайся опытом и учи (nemawashi)
Тоёда-сан пытался запустить производственный процесс, путешествовал по миру, учился, но долгое время ощутимых результатов не было. Однако все изменилось позже благодаря двум «воспитанникам» системы — Тайити Оно и Сигэо Синго, которые были в Toyota почти с самого начала.

Оно-сан, путешествуя по США, был поражен устройством работы супермаркетов: все точно находилось на полках тогда, когда это было нужно, и никакой суеты — в отличие от производства Toyota. Помня об идеях Тоёда-сан (Киитиро), он разработал концепцию Just-in-Time (JIT). Если по-простому — все должно быть на своих местах ровно в тот момент, когда это требуется, и только тогда. Если рабочему нужен ключ — он должен быть под рукой. Нужен компонент для монтажа — он тоже должен быть доступен.

Для реализации принципа были построены процессы внутренней доставки по системе Kanban — с использованием карточек-инструкций. Как в супермаркете: у покупателя есть список покупок, он наполняет корзину и доставляет ее куда нужно. Profit!

Точно вовремя (JIT)
Синго-сан, сотрудничая с Оно-сан, углубился еще дальше и заметил, что помимо нехватки материалов производство теряет время из-за дефектов оборудования и ошибок сотрудников. Можно ли устранить дефекты с минимальными временными затратами? Можно, если ремонтировать оборудование во время работы и знать, когда оно сломалось. Это называется быстрой переналадкой или Single-Minute Exchange of Dies (SMED).

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

Узнавай о проблеме и не давай делать ошибки (andon и poka-yoke)
После наладки механической части производства Синго-сан и Оно-сан поняли, что нужно обучать персонал. Но как объяснить процесс неподготовленному рабочему? Очень просто — с помощью Kanban-доски. Как и карточки на производстве, Kanban-доска наглядно показывает, из чего состоит процесс и какие операции нужно выполнить. Это упростило контроль и сделало обучение сотрудников более быстрым.

Показывай наглядно (Kanban)
Как видите, история сделала круг и система Kanban стала применяться повсеместно. Сегодня ее «заимствуют» все, делая вид, что в этом есть что-то сложное. Смешной факт: на нескольких собеседованиях интервьюеры утверждали, что я не знаю, как работать с Kanban. Наивные!

👉 @seniorFront

Windsurf vs Cursor IDE: кто лучший AI-редактор кода?

Две популярные IDE (среды разработки) с поддержкой искусственного интеллекта: Windsurf и Cursor. Оба инструмента заявляют, что ускорят процесс написания кода, но какой из них лучше подойдет именно вам? Я тщательно изучил обе, и в статье расскажу к каким выводам пришел.

👉 @seniorFront

Dropbox Color Picker

Вся сцена - это SVG картинка, анимируемая библиотекой gsap.

👉 @seniorFront

Next Prev & Hover Effects in JavaScript

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

👉 @seniorFront

"Боже, просто подай знак, могу ли я сегодня ничего не делать и списать 8 рабочих часов"

Бог:

👉 @seniorFront

Blurred Gear Loader

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

👉 @seniorFront

Image Slider

Слайдер, реализованный без использования JS, при помощи радио-кнопок.

👉 @seniorFront

Simple CSS Animation Effects

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

👉 @seniorFront

Toggle Dark

Переключатель, реализованный на чистых HTML и CSS.

👉 @seniorFront

Roman Numerals Encoder

Создайте функцию, принимающую в качестве параметра целое положительное число от 1 до 3999 (оба числа включены) и возвращающую строку, содержащую римское цифровое представление этого целого числа.

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

В римских цифрах:
1990 год записывается: 1000=M + 900=CM + 90=XC; в результате получается MCMXC.
2008 год записывается как 2000=ММ, 8=VIII; или MMVIII.
1666 год использует каждый римский символ в порядке убывания: MDCLXVI.

Пример:

   1 --> "I"
1000 --> "M"
1666 --> "MDCLXVI"

Справка:

символ - значение:

I        1
V        5
X       10
L       50
C      100
D      500
M    1,000

👉 @seniorFront

Топ-10 техник атак веб-приложений 2024 года

PortSwigger опубликовали топ-10 техник атак веб-приложений 2024 года, проекта, созданного усилиями сообщества, чтобы определить самые инновационные и важные исследования в области веб-безопасности, опубликованные за последний год.

👉 @seniorFront

​Зачем нужен виртуальный DOM?

Виртуальный DOM (Virtual DOM) — это концепция, используемая в современных фреймворках и библиотеках, таких как React, для оптимизации и ускорения работы с реальным DOM. Реальный DOM медленный при частых изменениях, поэтому виртуальный DOM решает эту проблему, делая процесс более эффективным.

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

Как он работает
1. Создание: Когда состояние приложения меняется, создаётся новый виртуальный DOM, представляющий обновлённое состояние.
2. Сравнение: Сравниваются старый и новый виртуальные DOM, чтобы определить, какие части реального DOM нужно обновить. Этот процесс называется "диффинг" (diffing).
3. Минимальные: После сравнения, в реальный DOM вносятся только необходимые изменения, что значительно снижает количество операций с ним.

Пример

import React, { useState } from 'react';

function Counter() {
  const [count, setCount] = useState(0);

  return (
    <div>
      <p>Вы нажали {count} раз</p>
      <button onClick={() => setCount(count + 1)}>
        Нажми меня
      </button>
    </div>
  );
}

export default Counter;

В этом примере при каждом изменении состояния count React создаёт новый виртуальный DOM, затем сравнивает его с предыдущим виртуальным DOM и применяет только те изменения, которые необходимы для реального DOM.

Преимущества
1. Повышение производительности: Благодаря уменьшению количества прямых операций с реальным DOM.
2. Кроссбраузерная совместимость: Виртуальный DOM позволяет абстрагироваться от специфичных для браузера особенностей работы с DOM.
3. Лёгкость обновлений и рендеринга: Использование виртуального DOM делает процесс обновления интерфейса приложения более предсказуемым и управляемым.

👉 @seniorFront

LED Controls

Оригинальные переключатели, реализованные на React и стилизованные в SCSS.

👉 @seniorFront

​Scrum-то какой! За что критикуют спринты

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

Четыре причины недовольства

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

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

3 — Проблемы междисциплинарности и потеря фокуса. Scrum-гайд отмечает, что в спринтах участвует команда, состоящая из скрам-мастера (одна штука), владельца продукта (одна штука) и разработчиков. Иных ролей в «каноничном» Scrum нет. На практике компании пытаются дооснастить команду не только менеджерами, но и другими специалистами (аналитиками, тестировщиками, юзабилистами), которые, с одной стороны, тоже должны принимать участие в процессе разработки, а с другой — с трудом втискиваются в прокрустово ложе фреймворка.

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

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

👉 @seniorFront

Как писать документацию, которую полюбят: 15 must-read книг (и не только)

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

👉 @seniorFront