〰️ 3️⃣ лучшие практики коммитов в GIT

Линус Торвальдс на днях сделал заявление:

Anyway, on a completely different note: I try to make my merge commit messages be somewhat "cohesive", and so I often edit the pull request language to match a more standard layout and language. It's not a big deal, and often it's literally just about whitespace so that we don't have fifteen different indentation models and bullet syntaxes. I generally do it as I read through the text anyway, so it's not like it makes extra work for me.

But what *does* make extra work is when some maintainers use passive voice, and then I try to actively rewrite the explanation (or, admittedly, sometimes I just decide I don't care quite enough about trying to make the messages sound the same).

So I would ask maintainers to please use active voice, and preferably just imperative.

Put another way: I'd love it if people would avoid writing their descriptions as "In this pull request, the Xyzzy driver error handling was fixed to avoid a NULL pointer dereference".

Instead write it as "This fixes a NULL pointer dereference in .." or particularly if you just list bullet points, make the bullet point just be "Fix NULL pointer dereference in ..".

This is not a big deal, I realize. But I happened to try to rewrite a few of these cases the last week, and I think simple and to-the-point language is better. The imperative version of just "Fix X" is about as clear as it gets.

А если по-русски и кратко, то он обращается к разработчикам ядра Линукс и просит писать текст к изменениям более понятным языком. Показалось полезным, поэтому вот советы для хороших коммитов:

1. Пишите описание кратко, в формате продолжения фразы "Это изменение исправит ...", например "fix image description".

2. Делайте коммит только полноценных изменений. Не нужно коммитить половину работу или непротестированные изменения.

3. Следуйте одному формату во всех коммитах.

Если вам интересно почитать подробнее, то вот советы от github и ресурс, посвященный идее сделать коммиты легко читаемыми людьми и машинами.

🍰 #it #просто_о_сложном

🔠🔠🔠: какую выбрать?

Если вы только изучаете SQL (супер-полезный пост тут), то вы точно задаётесь вопросом, какую систему для управления Базами Данных использовать. Скорее всего, вы выбираете из MySQL, PostrgeSQL и SQLite. Возможно вы смотрите на Oracle, ЯндексДБ или даже на Firebird.

〰️ А что-же стоит выбрать на самом деле? Ответ прост.

Вы можете выбрать любой инструмент, который решает вашу задачу. Особо разницы между ними нет, и скорее всего вы, как разработчик, будете использовать ORM. Если на работе вам придётся использовать другую БД, то опыт работы с любой другой будет вам только полезен. Главная проблема возникает в том случае, если вы выбираете непопулярную БД. тогда у вас точно спросят причину использования именно этой системы.

👁‍🗨 Как и в случае с другими инструментами, используйте популярные решения. Для этого читайте опросы и исследования рынка, как это делаю я (1, 2, 3, 4, 5). И самым популярным решением сейчас является PostgreSQL.

🍰 #it #мои_мысли

☠️ Проклятие знания

На днях я в очередной раз был в ГЭС-2 (и вам советую). Всё здание имеет общий, очень выразительный и аутентичный стиль, в котором сложно разобраться. В первый раз вы вряд ли поймёте, где находится столовая, гардероб и туалет (хотя в самом здании достаточно указателей, довольно понятная планировка и нет ничего лишнего).

Но посетив ГЭС-2 в третий или четвёртый раз вы будете легко ориентироваться и разметка будет выглядеть понятной и логичной. Почему так происходит?🤔

Есть такое конгитивное искажение — «проклятие знания».

Оно заключается в том, что более информированным людям сложно рассматривать какую-либо проблему с точки зрения менее информированных людей. Как и в случае с другими искажениями, мы даже часто не знаем о нём. "Проклятие знания" особенно сильно влияет на нас, когда мы делимся знаниями 🤓

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

☕️ Изучая новую тему - помните об этом. Зачастую новые знания не сложные, но из за того, что лектор столкнулся с этим искажением, вам будет ничего не понятно. Более того, коллеги лектора могут так же, как и сам лектор, воспринимать материал как очень понятный.

А вы сталкивались с таким «проклятием?» 🔽

🍰 #it #просто_о_сложном

💬 Почему решили сменить место работы?

Такой вопрос часто ставит соискателей в ступор. Разберёмся, как отвечать на него.

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

👎 В популярные ответы "не хватило роста в компании" или "нет развития" - я бы не поверил. Во-первых, вряд ли это так, во-вторых, вряд ли вы что-то делали для исправления этой ситуации. Дядя Боб отлично это дополняет своим высказыванием о том, что компания не обязана повышать ваш уровень как специалиста, это прежде всего ваша ответственность и инициатива!

➡️ Лучше всего ответить честно, но не надо говорить о том, что коллеги плохие и задачи не интересные. Подумайте, почему вы действительно хотите уволиться? Если считаете, что проблема не в вас, то подумайте ещё или перефразируйте ответ. Обязательно расскажите, что уже сообщили текущему руководству о поиске работы.

Примеры:

1. "При оформлении у нас были одни условия работы. В связи с реорганизацией компании они изменились и меня это не устраивает".

Объясните, что речь идёт, например, о обязательном посещении офиса. У нового работодателя, соответственно, это не должно быть обязательным условием работы. 🖥

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

Помните, что проблема скорее всего в вашем отношении и покажите, что вы над этим работаете. ⌛

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

Если вы хотите сменить работу с повышением, расскажите о том, что уже применяете нужные навыки и ваша мотивация не в повышении зарплаты. 💱

🍰 #it #it_собесы

🥇 А вы получили медальки на литкоде в этом году? Делитесь в комментариях!

Хочу записать миникурс про решение алгоритмов, но не понятно, будет ли вам интересно. Напомню, что у меня есть сайт с самыми полезными заданиями из литкода, пост про решение алгоритмов и концепции алгоритмов: 1 и 2. 📌

🍰 #it #алгоритмы

👻 Страшные тайны ООП

Всем привет! Завтра, в московском кампусе Школы 21, я проведу лекцию "Страшные тайны ООП". Приглашаю всех!

Выступление будет состоять из двух частей:
➡️ Первая для тех, кто мало знаком с ООП: разберёмся что это такое и как его использовать. Будут даже примеры на языке C!
➡️ Во второй части мы посмотрим на проблемы, с которыми можно столкнуться, используя ООП. Или как говорит Бьёрн Страуструп, "как отстрелить себе ногу".

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

🎁 Во время лекции разыграем мини-бокс сладостей к Хеллоуину, а первый, кто задаст вопрос после выступления, получит от меня менторский созвон.

Трансляция выступления будет тут

P.S: Кидайте свои любимые Хэллоуинские стикеры в комменты (я уже скинул)👇

🍰 #it #анонсы

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

User(name=name, email=email)

✏️ Мы можем упростить код и написать так:

User(name, email)

👀 А как насчёт такого варианта?

User(email, name)

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

⚡️ В языке Rust используются лучшие возможности всех языков и придумываются всё новые упрощения. И в нём есть такое решение, которое позволяет не сохранять порядок, если название атрибута соответствует названию переменной. Компилятор сам сопоставит нужные параметры и вы можете быть уверены, что три этих варианта будут работать одинаково:

User(name: name, email: email);
User(name, email);
User(email, name);

Я спросил у знакомых, которые пишут на других языках и выяснил, что больше нигде нет такого решения. Интересно, разработчики Rust сами придумали его, или это из какого-то другого языка? Видели ли вы где-то ещё такой подход?🔽

🍰 #it #просто_о_сложном

📥 Пишите TODO в коде!

Совет может показаться странным, но на самом деле, это действительно полезная вещь. Когда я только начинал свой путь в IT, я считал, что наличие комментариев показывает, что код плохой. А если это ещё и комментарий TODO(нужно сделать) то это вообще нельзя допускать в продакшн. Кажется, что такие комментарии лишь показывают вашу несостоятельность как разработчика.

На самом деле, наличие комментариев, особенно TODO - признак хорошего подхода к разработке! Обязательно пишите такие комментарии, когда видите, что часть кода реализована плохо или имеет смысл её переписать. Это актуально, когда найденная проблема не связана с вашей текущей задачей.

Разрабатывая программы, нам всегда приходится выбирать: сделать быстро или качественно.

👨‍💻 Зачастую бизнесу нужно быстрое решение задачи, поэтому у вас может не быть времени для исправления проблемы. Но вы можете помочь себе и продукту тем, что отметите возможность улучшения. Если в будущем у вас будет время на рефакторинг, то вы сможете вернуться к этому коду и исправить то, что отметили.

Не написав TODO-шку ,вы забудете о проблеме уже через пару минут. Лучше иметь проблему и знать о ней, чем вообще не знать о её существовании.

А вы пишите TODO?⬇️

🍰 #it #it_мнение

🏨 АРХИ-СОБЕС

🚀 Есть новость! Я готовлюсь к архитектурным собеседованиям. Есть план из 7 занятий с обязательными домашками. Нужны 1-2 человека, которые тоже хотят подготовиться.

Кто хочет со мной? Пишите в личку - и я скину первую домашку. Кто первый успеет сделать домашку к 18 ноября, с теми будем проходить подготовку.🙂

🍰 #it #архитектура_it

💵Почему IT-курсы такие дорогие? Или как я записал 2 курса.

Спойлер: это долго, дорого и сложно!

На производство одного часа видео нужно более 40 часов работы. А чтобы записать ±10 часов учебного видео-материала мне потребовался целый год! 🥸

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

⌛ После подготовки сценария его проверяют методист и куратор курса. 9 из 10 сценариев возвращаются на доработку. После того, как методист одобряет сценарий, идёт подготовка материалов: текст вычитывается редакторами, дизайнеры подготавливают презентацию, а куратор курса оформляет заметки/лонгрид/транскрипцию к уроку.

🎙Когда все материалы готовы, можно приступать к записи. Казалось бы - самое сложное позади! Но не тут-то было... Любая запись требует в три раза больше исходного материала. То есть для получения финального 5-минутного видео, вам нужно будет потратить порядка 15 минут для его записи. В процессе съёмки спикер всегда запинается, перезаписывает какие-то фразы или может даже молчать целую минуту.

▶️ После записи весь отснятый материал передаётся монтажёрам, которые подготавливают итоговый материал. Зачастую, к финальному материалу нужно написать ещё задания для студентов.

В итоге получается, что одно 20-минутное видео может занять суммарно более 40 человека-часов работы. Учитывая, что я работал с командой профессионалов, которые занимаются записью курсов уже много лет, мне нужно было не так много времени. Получилось примерно 8 часов работы на каждые 20 минут готовых видео.

💸За запись курсов спикеру (в данном случае мне) платят в три раза меньше, чем платят на обычной работе. В среднем, оплата одного видео составляет порядка 4000 рублей. Когда мы говорим, что эта цена за 20 минут, кажется, что это много. Но добавив информацию из прошлого абзаца мы получаем, что за полноценную работу по записи курсов зарплата была бы 85 000 рублей. Учитывая, что это не основная работа - это очень мало.

Я бы не стал записывать курсы ради получения дополнительных денег, принимая во внимание, что оплачивают только целиком готовый курс, а не постепенно по урокам. Отдельно можно отметить, что курс имеет «срок годности», и через 2 года технологии изменятся настолько, что он будет уже неактуален.

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

Запись курсов это не про деньги (как минимум для спикера) и цена за них для меня стала более оправдана. Если вы проходили платные курсы, то поделитесь в комментарии своим мнением как ученика.

А я планирую записать мини-курс про алгоритмы. Сделать его платным или бесплатным? 🔈

🍰 #it #it_мнение #it_курсы

⏩ SLA / SLI / SLO

Проектируя сервисы, мы сталкиваемся с тремя понятиями:
🔢Service Level Agreement,
🔢Service Level Indicators,
🔢Service Level Objectives.

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

Пример: Мы арендуем облако, поставщик гарантирует 99,9% доступности сервиса в месяц. При нарушении мы получаем депозит за каждый 0,1% недоступности.

🟥 SLI — это метрики, которые мы будем использовать для оценки выполнения SLA. В примере выше, SLI - это доступность сервиса. Мы можем измерять также скорость ответа от сервера в мс, если нам важна эффективность сервиса и пользовательский опыт.

🟩 SLO — это цели команды по выполнению SLI, зафиксированные в SLA. В нашем примере, метрикой SLI мы выбрали доступность сервиса. Это популярная метрика, для измерения которой используют "девятки".

У нас в примере целевой уровень для SLI равен 99,9% в месяц, значит что 0.1% времени сервис может быть недоступен. Т.к. в месяце у нас около 43 тысяч минут, недоступен сервис может быть 43 минуты. Этот уровень и есть SLO — то есть цель команды по конкретной метрике.

В итоге, SLA - это соглашение, в котором зафиксированы SLI, целевой уровень которых определён SLO.

Сла, сли, сло... Нам и без этого нормально работается...

🍰 #it #просто_о_сложном

👉 Пока мы готовим полезные материалы с трёх выступлений напомню:

🧑‍💻 Ко мне в команду требуется два стажёра. Если вы, или кто-то из ваших знакомых хочет заниматься тестированием или разработкой веба на Python, то кидайте резюме мне в личку -> @PySage

✍️ Даже если кажется, что не готовы выйти на работу, всё равно кидайте!

P.S: Если уже кидали, скиньте ещё раз и напишите куда хотите, в разработку или в тестирование.

🍰 #it #вакансии #It_материалы

🐰 Ну что коллеги, работаем?

В пятницу настроение только такое.

🍰 #it #капимем

🔠🔠🔠🔠🔠🔠🔠

Когда коллега просит посмотреть код, а там коджест 😊

За октябрь и ноябрь я написал полезные посты на разные темы:

⭐️ HR
〰️Что выбрать стартап или крупную компанию?
〰️Секрет поиска ✨ идеальной ✨ работы
〰️Отвечаем на вопрос "Почему решили уволиться?"

😳 Архитектура
〰️Виды Архитектуры ИС
〰️Разбираем понятия SLA/SLI/SLO
〰️Что такое Spark и Pandas
〰️Как выбрать SQL Базу Данных

🪄Полезности
〰️Изучаете новую тему и ничего не понятно? Это проклятие! Проклятие знания.
〰️Полезные практики работы с GIT
〰️Писать ли TODO в коде?
〰️Почему курсы такие дорогие

Про что написать ещё?

🍰 #it #коджест

⚙️ Как работает память компьютера?

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

🧠 Оперативная память
Это "краткосрочная" память компьютера. Она требует высоких энергозатрат и её сложно расширять. Зато эта память работает очень быстро. Мы знаем точный адрес, где мы храним данные, и мы можем быстро к ним обратиться. Причём за одну секунду можно прочитать всю ОЗУ на 20-50 гигабайт (в зависимости от системы) !

💥 Хранить в такой памяти можно не много. В соотношении, в оперативной памяти в 10-20 раз меньше единиц хранения, чем долговременной. Поскольку эта память энергозависима, то от перепада энергии/перезагрузки мы можем потерять все данные.

💿Долговременная память
Такая память храниться на жёстких дисках. Это могут быть HDD или более современные SDD. HDD работают как виниловый проигрыватель.

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

🔗 Хранить в такой памяти мы можем много, но считывать должны целыми блоками (например всю строку базы данных), даже если нам нужна лишь небольшая часть. Из-за особенностей работы скорость будет значительно ниже. Те же 20 гигабайт мы прочитаем в среднем за 20 секунд. Зато память на жёстких дисках энерго независима, и перезагрузка не приведёт к удалению данных.

🌐 Память процессора
Ещё быстрее работает память на самом процессоре, но она сильно ограничена. На одном ядре размещается до 64 Мб. Эта память используется для текущих расчётов самим процессором. Это уровень регистров и кэша процессора.

Заметка для удобства:

|  Тип памяти  | Cкорость |      Объем    |
| ------------ | -------- | ------------- |
|  Регистры    |   <1 нс  |     До 1 КБ   |
|    L1-кэш    |   ~1 нс  |    16–128 КБ  |
|    L2-кэш    |   ~5 нс  | 256 КБ – 2 МБ |
|    L3-кэш    |  ~20 нс  |     4–64 МБ   |
|      ОЗУ     |  ~100 нс |       ГБ      |
|  SSD (NVMe)  | ~100 мкс |       ТБ      |
| HDD(7K RPM)  | ~5–10 мс |       ТБ      |

🍰 #it #просто_о_сложном

Что не так со Школой 2️⃣1️⃣?

Как вы знаете, я выпускник Школы 21, и уже много раз выступал там с разными темами (наверняка вы периодически видите анонсы в канале).

В целом мне нравится подход Школы, особенно то, что она полностью бесплатная😁. Однако есть и негативные моменты. Но только на днях я смог сформулировать, что же мне не нравится в обучении Школы (далее s21). Возможно, эту проблему вы тоже замечали, так что делитесь в комментариях своим мнением, буду рад обсудить!

➡️ Для начала, как вообще построено обучение в s21:
Вам дают задачу связанную с разработкой. Например, "напишите скрипт на Bash...", а вы не знаете, что такое Bash или даже что такое "скрипт". В школе нет преподавателей, нет базы знаний, вы должны сами найти информацию и решить задачу. В итоге, вы ёе сделаете (или нет). Найдёте ответы на все вопросы, изучите технологию и напишите этот скрипт.

Этот подход развивает один из самых важных, если не самый важный навык: самостоятельно находить решение любой проблемы. Это очень полезно на работе, особенно в IT.

⚡️ Проходя обучение в s21, вы будете постоянно сталкиваться с неудачами. Многие часы тратить на безуспешные попытки починить то, что уже целое. Десятки раз выбирать неверные пути решения. На сотни и тысячи неудачных попыток вы будете получать только одну удачную. Это тоже полезно. Формируется критически важный для разработчика навык - не сдаваться и знать, что однажды твой код заработает.

🙂 Что же не так?
Вы не попадёте в команду лучших разработчиков. Это нужно понять сразу. Шансов, что с вами будут работать лучшие - очень низкий. Разработчики тоже люди, причём часто с не очень хорошими софт-скиллами.

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

🔘А что в итоге?
Индустрия получает большое количество специалистов, но они не знают о лучших практиках. Если вы обучились в s21, вам нужно самостоятельно изучить их и внедрять их в работу. Это соответствует подходу школы, но не помогает развивать сообщество разработчиков. Вы вряд ли узнаете лучшие практики без опыта работы в командах высокого уровня, а шанс попасть в такую - очень маленький.

Не обязательно даже создавать новые стандарты, можно использовать чужие. У Google есть много полезных, например практики код ревью. Кажется, что стоило бы внедрять в обучение такие практики и помогать развивать индустрию.

А как считаете вы? Встречали команды высокого уровня, где процессы помогают работать эффективно, коллеги имеют имеют экспертное мнение, а продукт — инновация в сфере? 🔽

🍰 #it #мысли

👉Как делать красивые эдпоинты

Придумать название переменной и описание коммита — проблема каждого разработчика. Составить правильно эндпоинт в REST приложении — проблема не менее редкая. Прежде, чем читать дальше подумайте, что не так с этим эндпоинтом:

/api/GetLastUserPost/?id=123

🐸 Давайте улучшим его за 5 шагов!
1⃣ В конце маршрута убираем "/".
Параметры запроса не нужно отделять дополнительным разделителем:

/api/GetLastUserPost?id=123

2⃣ Определяем иерархию.
Выделите сущности и определите их связи. У нас есть пользователь у которого есть посты. Оставьте 1-2 вложенные сущности. Например, если пользователь входит в дополнительную группу, но его id уникален, можно начать сразу с пользователя:

/api/user/123/GetLastPost

3⃣ Семантический (человекопонятный) URL.
Для разделения слов в ссылке используйте "-" и начинайте все слова с прописной буквы(kebab-case):

/api/user/123/get-last-post

4⃣ Действие определяется методом.
Не нужно прописывать действия с объектом. Метод должен соответствовать действию, с которым мы делаем запрос:

GET: /api/user/123/last-post

5⃣ Использование множественной формы.
Указание конкретного id пользователя показывает, что мы работаем с группой users. Если вы делаете запрос с параметром объекта из группы, то группа указывается во множественном числе:

GET: /api/users/123/last-post

🍰 #it #просто_о_сложном

🔒 Безопасность при написании кода

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

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

Теперь, когда я пишу код или делаю ревью, я думаю о безопасности. Если я вижу обращение по индексу, то проверяю, что до этого была проверка на существование этого индекса. Это снижает скорость разработки и добавляет код. В каких-то случаях этот подход выглядит даже не типичным для Python. Но зато теперь я уверен, что в продакшен эта часть кода будет работать именно так, как мы задумывали.

⚙️ Другой интересный подход из rust - это гарантии интерфейсов. Если вы пишите функцию, то она должна гарантировать, какой тип данных она вернёт и может ли она вызвать ошибку.

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

А на каком языке пишите вы?🔽

🍰 #it #мысли #инсайт

Хотите телеграм премиум? ⭐️

Давайте устроим интерактив 🪐
Напишите в комментарий самый полезный для вас пост в канале, первый который приходит на ум. Ну или просто отправьте любимый стикер. А я устрою розыгрыш премиум подписок в канале. Комментарии от 20 разных людей до НГ == розыгрыш 3 премиумов.

Если у вас уже есть премиум сделайте буст канал, что бы вернуть красивое оформление
▶️https://t.iss.one/boost/a_cup_of_code

Написать комментарий про самый полезный пост или скинуть любимый стикер ⬇️

🍰 #it #розыгрыш