Media is too big
VIEW IN TELEGRAM
Stunning CSS SVG Animation Effects
В этом видео создается SVG картинка, которая затем анимируется в CSS.
👉 @seniorFront
В этом видео создается SVG картинка, которая затем анимируется в CSS.
👉 @seniorFront
Is a number prime?
Создайте функцию, которая принимает целочисленный аргумент и возвращает логическое значение true или false в зависимости от того, является ли это целое число простым.
Согласно Википедии, простое число (или прайм) - это натуральное число больше 1, которое не имеет положительных делителей, кроме 1 и самого себя.
Требования
- Вы можете предположить, что вам будет задано целое число.
- Вы не можете предполагать, что это целое число будет только положительным. Вам могут быть даны и отрицательные числа ( или 0 ).
- Замечание по производительности: Не требуется никаких причудливых оптимизаций, но все же самые тривиальные решения могут выходить из строя. Числа доходят до 2^31 ( или аналогично, в зависимости от языка ). Циклы до n или n/2 будут слишком медленными.
Пример
👉 @seniorFront
Создайте функцию, которая принимает целочисленный аргумент и возвращает логическое значение true или false в зависимости от того, является ли это целое число простым.
Согласно Википедии, простое число (или прайм) - это натуральное число больше 1, которое не имеет положительных делителей, кроме 1 и самого себя.
Требования
- Вы можете предположить, что вам будет задано целое число.
- Вы не можете предполагать, что это целое число будет только положительным. Вам могут быть даны и отрицательные числа ( или 0 ).
- Замечание по производительности: Не требуется никаких причудливых оптимизаций, но все же самые тривиальные решения могут выходить из строя. Числа доходят до 2^31 ( или аналогично, в зависимости от языка ). Циклы до n или n/2 будут слишком медленными.
Пример
is_prime(1) /* false */
is_prime(2) /* true */
is_prime(-1) /* false */
👉 @seniorFront
👍1
Чистый код — красивая архитектура. А работает ли это?
Вы пишете код не для компилятора — он съест любую абракадабру, если синтаксис верен. Вы пишете для людей, для того парня из соседнего отдела, который будет разбирать ваш код через полгода. Для себя, когда забудете, о чём думали в момент написания. Для тимлида, у которого нет времени расшифровывать ваши «фичи», замаскированные под техдолг.
Грязный код — это про непонятные переменные, запутанные модули и решения «на скорую руку». Вас ждёт после такого потеря во времени и в лучшем случае косые взгляды коллег. К сожалению, непонятный код часто пишут не только из-за спешки, но и из-за неопытности и чрезмерного энтузиазма тех, кто хочет всё переделать.
Давайте разберём, как превратить кошмар в конфетку — детали внутри.
👉 @seniorFront
Вы пишете код не для компилятора — он съест любую абракадабру, если синтаксис верен. Вы пишете для людей, для того парня из соседнего отдела, который будет разбирать ваш код через полгода. Для себя, когда забудете, о чём думали в момент написания. Для тимлида, у которого нет времени расшифровывать ваши «фичи», замаскированные под техдолг.
Грязный код — это про непонятные переменные, запутанные модули и решения «на скорую руку». Вас ждёт после такого потеря во времени и в лучшем случае косые взгляды коллег. К сожалению, непонятный код часто пишут не только из-за спешки, но и из-за неопытности и чрезмерного энтузиазма тех, кто хочет всё переделать.
Давайте разберём, как превратить кошмар в конфетку — детали внутри.
👉 @seniorFront
🔥3🤔1
Что такое прототипное наследование?
Это механизм, с помощью которого объекты могут наследовать свойства и методы от других объектов. Это одна из основных особенностей языка JavaScript, отличающая его от классических моделей наследования, используемых во многих других языках программирования.
Как это работает
Каждый объект имеет специальное скрытое свойство
Пример:
В этом примере объект
Основные принципы
- Прототипная цепочка: Когда вы обращаетесь к свойству объекта, автоматически ищет это свойство в объекте, а затем — в его прототипах, пока не достигнет конца цепочки прототипов.
-
- Создание объектов с определённым прототипом: Для создания объектов с указанием прототипа можно использовать
Отличия от классического наследования
В отличие от него, прототипное наследование не использует классы как таковые (до введения
👉 @seniorFront
Это механизм, с помощью которого объекты могут наследовать свойства и методы от других объектов. Это одна из основных особенностей языка JavaScript, отличающая его от классических моделей наследования, используемых во многих других языках программирования.
Как это работает
Каждый объект имеет специальное скрытое свойство
[[Prototype]] (как правило, доступное как proto или через Object.getPrototypeOf()), которое ссылается на другой объект — его прототип. Когда вы пытаетесь получить доступ к свойству или методу объекта, и это свойство/метод не найдено в самом объекте, поиск продолжается по цепочке прототипов, пока свойство/метод не будет найден или не будет достигнут конец цепочки прототипов (прототип null).Пример:
let animal = {
eats: true,
walk() {
console.log("Animal walk");
}
};
let rabbit = {
jumps: true,
proto: animal
};
rabbit.walk(); // Animal walk
console.log(rabbit.eats); // trueВ этом примере объект
rabbit наследует свойство eats и метод walk от объекта animal через прототипную цепочку.Основные принципы
- Прототипная цепочка: Когда вы обращаетесь к свойству объекта, автоматически ищет это свойство в объекте, а затем — в его прототипах, пока не достигнет конца цепочки прототипов.
-
Object.prototype: В вершине прототипной цепочки находится Object.prototype. Он не имеет прототипа и содержит методы, доступные всем объектам, такие как toString(), hasOwnProperty() и другие.- Создание объектов с определённым прототипом: Для создания объектов с указанием прототипа можно использовать
Object.create(proto), где proto — объект, который должен стать прототипом для нового объекта.Отличия от классического наследования
В отличие от него, прототипное наследование не использует классы как таковые (до введения
class в ES6, которые являются "синтаксическим сахаром" над прототипным наследованием). Вместо этого объекты напрямую наследуют свойства и методы от других объектов.👉 @seniorFront
👍4
Почему микро-сервисы редко взлетают?
Потому, что микро-сервисы часто оказываются не «микро», а «нано» сервисами. «Микро» — это не «нано», микро-сервисы устроены иначе. Не скажу, что знаю рецепт хорошего микро-сервиса. Но я постараюсь показать, каким он точно не должен быть.
Давайте дадим определение микро-сервису через аналогию: микро-сервис — как блюдо. Про него можно сказать следующее:
- Блюдо изолировано: каждое находится в свой тарелке. Или, если хотите, в контейнере.
- Блюда имеют ограниченный контекст. Плов — это плов, его не мешают с фруктами. Потребитель получает то, за что платит по меню.
- Блюда слабо связаны между собой. После тарелки любого супа можно взять любой гарнир. А можно и не брать. Бывают, конечно, ограничения: не стоит запивать селедку молоком. Но это — исключение.
- Блюда масштабируются. Мало одной котлеты — можно съесть две.
- Блюда легко тестируются. Их можно дегустировать по-отдельности.
- Блюда индивидуально конфигурируются. Можно взять борщ с пампушкой, можно — без.
По описанию получилось вполне съедобно, не так ли? Так почему же внедрение микро-сервисов так редко заканчивается успехом? Я не буду разглагольствовать про неверное разграничение контекста и другие пороки. Про них и так много сказано. Сфокусируюсь на одном.
Корень проблемы — неверная область использования микро-сервисов.
Микро-сервисы применяются не там и не так.
Микро-сервисы задумывались как альтернатива монолиту, который пилят десятки разработчиков. А сейчас все работают по Agile, команды маленькие. Работают или над своим небольшим продуктом, или над частью общего продукта компании.
Продукт (часть продукта) уже имеет изолированный контекст и слабые зависимости. С другими продуктами (частями) общается по API. Имеет свой технологический стек. Владеет отдельным хранилищем (базой). Независимо разворачивается. И даже имеет свою команду «на две пиццы».
По совокупности признаков, он уже микро-сервис! Продукт является готовым блюдом для потребителей.
Но нет! Каждая команда считает свой салатик монолитом. И поэтому берет, и делит на микро-сервисы. Что же у нее получается в итоге? Правильно: нано-сервисы!
Вместо того чтобы смешать все ингредиенты и приготовить блюдо, команда любовно расфасовывает ингредиенты по контейнерам. Но все-таки салат — это не то же самое, что запчасти для салата.
Если вам вместо трех блюд подадут тридцать ингредиентов в отдельных тарелочках, думаю, вы вряд ли посчитаете это хорошим обслуживанием.
Готовьте микро-сервисы правильно.
Многие компании целиком поражены болезнью чрезмерной декомпозиции. То и дело говорят: «у нас 30 команд и 1500+ микро-сервисов». И ведь искренне еще гордятся этим! Забывая рассказать про свои затраты на инфраструктуру. Рассказать, что новый разработчик до полугода погружается в эти сервисы. Что локализация обычного бага занимает у него неделю.
После всего сказанного позволю себе один совет:
Не дробите ваш маленький продукт на нано-сервисы. Это его убьёт. Он хороший. Дайте ему шанс повзрослеть.
👉 @seniorFront
Потому, что микро-сервисы часто оказываются не «микро», а «нано» сервисами. «Микро» — это не «нано», микро-сервисы устроены иначе. Не скажу, что знаю рецепт хорошего микро-сервиса. Но я постараюсь показать, каким он точно не должен быть.
Давайте дадим определение микро-сервису через аналогию: микро-сервис — как блюдо. Про него можно сказать следующее:
- Блюдо изолировано: каждое находится в свой тарелке. Или, если хотите, в контейнере.
- Блюда имеют ограниченный контекст. Плов — это плов, его не мешают с фруктами. Потребитель получает то, за что платит по меню.
- Блюда слабо связаны между собой. После тарелки любого супа можно взять любой гарнир. А можно и не брать. Бывают, конечно, ограничения: не стоит запивать селедку молоком. Но это — исключение.
- Блюда масштабируются. Мало одной котлеты — можно съесть две.
- Блюда легко тестируются. Их можно дегустировать по-отдельности.
- Блюда индивидуально конфигурируются. Можно взять борщ с пампушкой, можно — без.
По описанию получилось вполне съедобно, не так ли? Так почему же внедрение микро-сервисов так редко заканчивается успехом? Я не буду разглагольствовать про неверное разграничение контекста и другие пороки. Про них и так много сказано. Сфокусируюсь на одном.
Корень проблемы — неверная область использования микро-сервисов.
Микро-сервисы применяются не там и не так.
Микро-сервисы задумывались как альтернатива монолиту, который пилят десятки разработчиков. А сейчас все работают по Agile, команды маленькие. Работают или над своим небольшим продуктом, или над частью общего продукта компании.
Продукт (часть продукта) уже имеет изолированный контекст и слабые зависимости. С другими продуктами (частями) общается по API. Имеет свой технологический стек. Владеет отдельным хранилищем (базой). Независимо разворачивается. И даже имеет свою команду «на две пиццы».
По совокупности признаков, он уже микро-сервис! Продукт является готовым блюдом для потребителей.
Но нет! Каждая команда считает свой салатик монолитом. И поэтому берет, и делит на микро-сервисы. Что же у нее получается в итоге? Правильно: нано-сервисы!
Вместо того чтобы смешать все ингредиенты и приготовить блюдо, команда любовно расфасовывает ингредиенты по контейнерам. Но все-таки салат — это не то же самое, что запчасти для салата.
Если вам вместо трех блюд подадут тридцать ингредиентов в отдельных тарелочках, думаю, вы вряд ли посчитаете это хорошим обслуживанием.
Готовьте микро-сервисы правильно.
Многие компании целиком поражены болезнью чрезмерной декомпозиции. То и дело говорят: «у нас 30 команд и 1500+ микро-сервисов». И ведь искренне еще гордятся этим! Забывая рассказать про свои затраты на инфраструктуру. Рассказать, что новый разработчик до полугода погружается в эти сервисы. Что локализация обычного бага занимает у него неделю.
После всего сказанного позволю себе один совет:
Не дробите ваш маленький продукт на нано-сервисы. Это его убьёт. Он хороший. Дайте ему шанс повзрослеть.
👉 @seniorFront
❤5
«Кем Вы видите себя через 5 лет», или HRско-русский разговорник
Вас спрашивали «Кем Вы видите себя через 5 лет»? Меня тоже. За двадцать пять лет в IT я понял, зачем они так делают. Понял – это значит, что я «привык и научился пользоваться» (С). Но «неприятно удивлять» они меня не перестали.
Публикую свой личный русско-HRский разговорник. Он вряд ли поменяет ваше отношение к HRскому языку, но проходить собеседования вы будете проще и эффективнее.
👉 @seniorFront
Вас спрашивали «Кем Вы видите себя через 5 лет»? Меня тоже. За двадцать пять лет в IT я понял, зачем они так делают. Понял – это значит, что я «привык и научился пользоваться» (С). Но «неприятно удивлять» они меня не перестали.
Публикую свой личный русско-HRский разговорник. Он вряд ли поменяет ваше отношение к HRскому языку, но проходить собеседования вы будете проще и эффективнее.
👉 @seniorFront
Media is too big
VIEW IN TELEGRAM
Responsive Conatct Info Section
В этом видео создаются карточки контактов, анимируемые при наведении на них.
👉 @seniorFront
В этом видео создаются карточки контактов, анимируемые при наведении на них.
👉 @seniorFront
This media is not supported in your browser
VIEW IN TELEGRAM
Retro futuristic radio buttons
Кнопки созданы на HTML и CSS. При нажатии запускается анимация, реализованная с использованием библиотеки gsap.
👉 @seniorFront
Кнопки созданы на HTML и CSS. При нажатии запускается анимация, реализованная с использованием библиотеки gsap.
👉 @seniorFront
👍4❤1🔥1
Какой протокол используется для двустороннего обмена данными в реальном времени, например, в чатах?
Anonymous Quiz
7%
FTP
3%
IMAP
84%
WebSocket
6%
SMTP
❤2👍2
Sum of a sequence
Ваша задача - написать функцию, которая возвращает сумму последовательности целых чисел.
Последовательность задается 3 неотрицательными значениями: begin, end, step. Если значение begin больше end, то ваша функция должна вернуть 0.
Если end не является результатом целого числа шагов, то не добавляйте его к сумме. Смотрите 4-й пример ниже. Примеры
👉 @seniorFront
Ваша задача - написать функцию, которая возвращает сумму последовательности целых чисел.
Последовательность задается 3 неотрицательными значениями: begin, end, step. Если значение begin больше end, то ваша функция должна вернуть 0.
Если end не является результатом целого числа шагов, то не добавляйте его к сумме. Смотрите 4-й пример ниже. Примеры
2,2,2 --> 2
2,6,2 --> 12 (2 + 4 + 6)
1,5,1 --> 15 (1 + 2 + 3 + 4 + 5)
1,5,3 --> 5 (1 + 4)
👉 @seniorFront
👍1
Откуда растут переработки и прочая корпоративная шиза?
Почему в современном менеджменте столько глупости? Почему руководители верят в переработки, садистское отношение к сотрудникам и не умеют думать на 2 шага вперёд? Разберем в статье.
👉 @seniorFront
Почему в современном менеджменте столько глупости? Почему руководители верят в переработки, садистское отношение к сотрудникам и не умеют думать на 2 шага вперёд? Разберем в статье.
👉 @seniorFront
Что такое селектор атрибутов?
Позволяют выбирать элементы HTML на основе наличия, значения или частичного соответствия атрибутов. Это мощный инструмент, который делает стилизацию элементов более гибкой и точной.
Селектор по наличию атрибута
Выбирает элементы, которые содержат указанный атрибут, независимо от его значения.
Селектор по точному значению атрибута
Выбирает элементы, атрибут которых имеет точное указанное значение.
Селектор по наличию значения в списке значений атрибута
Выбирает элементы, атрибут которых содержит указанное значение в списке, разделенном пробелами.
Селектор по начальной части значения атрибута
Выбирает элементы, атрибут которых начинается с указанного значения.
Селектор по конечной части значения атрибута
Выбирает элементы, атрибут которых заканчивается на указанное значение.
Селектор по вхождению значения в атрибут
Выбирает элементы, атрибут которых содержит указанное значение в любом месте.
Примеры использования селекторов атрибутов
Стилизация всех изображений с атрибутом alt
Стилизация ссылок, ведущих на внешние сайты
Стилизация полей ввода с определенным типом
Стилизация элементов с определенным классом
Комбинированные селекторы
Селекторы атрибутов можно комбинировать с другими типами селекторов для создания более специфичных правил.
👉 @seniorFront
Позволяют выбирать элементы HTML на основе наличия, значения или частичного соответствия атрибутов. Это мощный инструмент, который делает стилизацию элементов более гибкой и точной.
Селектор по наличию атрибута
Выбирает элементы, которые содержат указанный атрибут, независимо от его значения.
/* Выбирает все элементы с атрибутом title */
[title] {
color: blue;
}
Селектор по точному значению атрибута
Выбирает элементы, атрибут которых имеет точное указанное значение.
/* Выбирает все элементы с атрибутом type, равным "submit" */
input[type="submit"] {
background-color: green;
}
Селектор по наличию значения в списке значений атрибута
Выбирает элементы, атрибут которых содержит указанное значение в списке, разделенном пробелами.
/* Выбирает все элементы с классом, включающим "btn" */
[class~="btn"] {
font-weight: bold;
}
Селектор по начальной части значения атрибута
Выбирает элементы, атрибут которых начинается с указанного значения.
/* Выбирает все элементы, значение атрибута href которых начинается с "https" */
a[href^="https"] {
color: red;
}
Селектор по конечной части значения атрибута
Выбирает элементы, атрибут которых заканчивается на указанное значение.
/* Выбирает все элементы, значение атрибута href которых заканчивается на ".pdf" */
a[href$=".pdf"] {
text-decoration: underline;
}
Селектор по вхождению значения в атрибут
Выбирает элементы, атрибут которых содержит указанное значение в любом месте.
/* Выбирает все элементы, значение атрибута href которых содержит "example" */
a[href*="example"] {
color: orange;
}
Примеры использования селекторов атрибутов
Стилизация всех изображений с атрибутом alt
img[alt] {
border: 2px solid blue;
}Стилизация ссылок, ведущих на внешние сайты
a[href^="http"] {
color: red;
}Стилизация полей ввода с определенным типом
input[type="text"] {
border: 1px solid gray;
}Стилизация элементов с определенным классом
[class~="button"] {
padding: 10px;
background-color: lightgray;
}Комбинированные селекторы
Селекторы атрибутов можно комбинировать с другими типами селекторов для создания более специфичных правил.
/* Выбирает все кнопки с классом btn и типом submit */
button.btn[type="submit"] {
background-color: green;
color: white;
}
👉 @seniorFront
👍8❤3
This media is not supported in your browser
VIEW IN TELEGRAM
Make the web less boring
Свёрстано на HTML и SCSS. Анимация реализована при помощи библиотеки Splitting.
👉 @seniorFront
Свёрстано на HTML и SCSS. Анимация реализована при помощи библиотеки Splitting.
👉 @seniorFront
👍3👎1🔥1
Когда разработчик тебе врёт: прокрастинация, отмазки и что с этим делать
Бро, если ты хоть раз руководил командой — ты это проходил. На стендапе всё звучит красиво: «делаю задачу, осталось чуть‑чуть», «почти готово», «просто баг странный». А потом проходит неделя, ты заглядываешь в код — и там либо ничего, либо половина сделано, либо вообще не туда копали.
Нет, это не обязательно саботаж. Иногда это банальная прокрастинация, страх ошибиться, потеря мотивации, или просто неумение сказать: «я застрял». Но проблема‑то реальная. Если не ловить и не разруливать — команда тонет в самообмане, а ты — в вечных переносах.
Что с этим делать (без угроз и тотального контроля)
1. Перевести коммуникацию в честный режим
Объясни, что красиво — не значит правильно. Лучше знать о залипании на старте, чем потом спасать сроки всей командой. Разработчик должен понимать, что от его темпа зависят не только задачи в трекере, но и работа коллег, планирование, демо, интеграции. Поделись кейсом, где сам застревал, ошибался, или делал что‑то неэффективно.
2. Ввести демо
Показывать прогресс не в конце спринта, а каждые 2–3 дня. Даже если это мок, даже если недоделано. Смысл — в процессе. Когда человек знает, что будет показ — он меньше залипает и раньше поднимает флаг, если что‑то не так.
3. Работать с мотивацией
Если кто‑то тупит — не значит, что он лентяй. Иногда у человека в жизни творится трэш. Иногда он просто перегорел. Иногда он не понимает, зачем делает задачу.
Не лечи всех одинаково. Один залип — потому что скучно. Другой — потому что боится. Третий — потому что его никто не слушает. И каждому нужен свой подход.
4. Использовать таймбоксинг
Не «сделай, когда сделаешь», а «поработай 2 часа — и скажи, зашло или нет». Это снижает тревожность, даёт точку выхода, и позволяет вовремя вытащить человека из тупика, а не после трёх дней молчания.
5. 1:1 как точка перехвата
Раз в неделю/две — короткая личная встреча. Без контроля. Просто поговорить. Часто люди на стендапе играют уверенность, а на 1:1 выдыхают и говорят, как есть. Слушай, не перебивай, не лечи. Иногда просто выговориться — уже половина решения.
6. Немного чайки - иногда работает
Да, чайка‑менеджмент — зло. Но иногда подлететь, пингануть и улететь — это встряска. Главное — не делать это стилем управления, а применять осознанно и дозировано как лекарства. Иногда это позволяет разбудить команду.
7. Парное программирование
Если задача критична — подключи второго. Даже если это джун. Когда работает пара, залипнуть труднее. А если один решит уйти в закат — второй хотя бы будет в курсе, что происходит.
8. Регулярное ревью кода и процессов
Не формальное, а живое. С разбором решений, обсуждением сложностей, поиском альтернатив. Часто человек тянет, потому что не уверен. А ревью снимает это напряжение и не даёт уйти в глухую оборону.
👉 @seniorFront
Бро, если ты хоть раз руководил командой — ты это проходил. На стендапе всё звучит красиво: «делаю задачу, осталось чуть‑чуть», «почти готово», «просто баг странный». А потом проходит неделя, ты заглядываешь в код — и там либо ничего, либо половина сделано, либо вообще не туда копали.
Нет, это не обязательно саботаж. Иногда это банальная прокрастинация, страх ошибиться, потеря мотивации, или просто неумение сказать: «я застрял». Но проблема‑то реальная. Если не ловить и не разруливать — команда тонет в самообмане, а ты — в вечных переносах.
Что с этим делать (без угроз и тотального контроля)
1. Перевести коммуникацию в честный режим
Объясни, что красиво — не значит правильно. Лучше знать о залипании на старте, чем потом спасать сроки всей командой. Разработчик должен понимать, что от его темпа зависят не только задачи в трекере, но и работа коллег, планирование, демо, интеграции. Поделись кейсом, где сам застревал, ошибался, или делал что‑то неэффективно.
2. Ввести демо
Показывать прогресс не в конце спринта, а каждые 2–3 дня. Даже если это мок, даже если недоделано. Смысл — в процессе. Когда человек знает, что будет показ — он меньше залипает и раньше поднимает флаг, если что‑то не так.
3. Работать с мотивацией
Если кто‑то тупит — не значит, что он лентяй. Иногда у человека в жизни творится трэш. Иногда он просто перегорел. Иногда он не понимает, зачем делает задачу.
Не лечи всех одинаково. Один залип — потому что скучно. Другой — потому что боится. Третий — потому что его никто не слушает. И каждому нужен свой подход.
4. Использовать таймбоксинг
Не «сделай, когда сделаешь», а «поработай 2 часа — и скажи, зашло или нет». Это снижает тревожность, даёт точку выхода, и позволяет вовремя вытащить человека из тупика, а не после трёх дней молчания.
5. 1:1 как точка перехвата
Раз в неделю/две — короткая личная встреча. Без контроля. Просто поговорить. Часто люди на стендапе играют уверенность, а на 1:1 выдыхают и говорят, как есть. Слушай, не перебивай, не лечи. Иногда просто выговориться — уже половина решения.
6. Немного чайки - иногда работает
Да, чайка‑менеджмент — зло. Но иногда подлететь, пингануть и улететь — это встряска. Главное — не делать это стилем управления, а применять осознанно и дозировано как лекарства. Иногда это позволяет разбудить команду.
7. Парное программирование
Если задача критична — подключи второго. Даже если это джун. Когда работает пара, залипнуть труднее. А если один решит уйти в закат — второй хотя бы будет в курсе, что происходит.
8. Регулярное ревью кода и процессов
Не формальное, а живое. С разбором решений, обсуждением сложностей, поиском альтернатив. Часто человек тянет, потому что не уверен. А ревью снимает это напряжение и не даёт уйти в глухую оборону.
👉 @seniorFront
❤10👍4