Секрет оптимизации SQL-запросов — понимание порядка выполнения последних.
📺 Смотреть подробнее
#проектирование_систем #easy
#проектирование_систем #easy
Please open Telegram to view this post
VIEW IN TELEGRAM
Краеугольные камни ООП по полочкам:
▫️Абстракция — модель объекта, в которой опущены незначительные детали, не играющие существенной роли в данном контексте
▫️Инкапсуляция — способность объектов скрывать часть состояния и поведения от других объектов, предоставляя внешнему миру только определенный интерфейс взаимодействия с собой
▫️Наследование — возможность создания новых классов на основе существующих
▫️Полиморфизм — способность программы выбирать различные реализации при вызове операций с одним и тем же названием
Можете объяснить более понятно и кратко? Ждем в комментариях.⬇️
#вопросы_с_собесов #easy
▫️Абстракция — модель объекта, в которой опущены незначительные детали, не играющие существенной роли в данном контексте
▫️Инкапсуляция — способность объектов скрывать часть состояния и поведения от других объектов, предоставляя внешнему миру только определенный интерфейс взаимодействия с собой
▫️Наследование — возможность создания новых классов на основе существующих
▫️Полиморфизм — способность программы выбирать различные реализации при вызове операций с одним и тем же названием
Можете объяснить более понятно и кратко? Ждем в комментариях.⬇️
#вопросы_с_собесов #easy
DevOps vs SRE vs Platform Engineering: в чем разница этих концепций/методолигий/практик?
📌 DevOps — помогает наладить эффективное взаимодействие команд разработки ПО и ИТ‑команд
📌 SRE — обеспечивает бесперебойную работу высоконагруженных сервисов
📌 Platform Engineering — создает инфраструктуру и инструменты для разработки продуктов, расширяя практики DevOps и SRE
#easy
📌 DevOps — помогает наладить эффективное взаимодействие команд разработки ПО и ИТ‑команд
📌 SRE — обеспечивает бесперебойную работу высоконагруженных сервисов
📌 Platform Engineering — создает инфраструктуру и инструменты для разработки продуктов, расширяя практики DevOps и SRE
#easy
Наглядная демонстрация различий между URL, URI и URN от Alex Xu
🔹 URI (Uniform Resource Identifier) идентифицирует логический или физический ресурс в Интернете. URL и URN являются подтипами URI.
🔹 URL (Uniform Resource Locator) — адрес уникального ресурса в Интернете, который в том числе можно использовать с другими протоколами.
🔹 URN (Uniform Resource Name) — использует схему URN и не может быть использовано для поиска ресурса.
#easy
🔹 URI (Uniform Resource Identifier) идентифицирует логический или физический ресурс в Интернете. URL и URN являются подтипами URI.
🔹 URL (Uniform Resource Locator) — адрес уникального ресурса в Интернете, который в том числе можно использовать с другими протоколами.
🔹 URN (Uniform Resource Name) — использует схему URN и не может быть использовано для поиска ресурса.
#easy
Помните затрагивали основные концепции ООП? Так вот, между объектами есть ещё несколько видов отношений, о которых важно знать. Разберем их кратко:
🔸Реализация: класс А определяет методы, объявленные интерфейсом B. Объекты А можно рассматривать через интерфейс B. Класс А зависит от B.
🔸Наследование: класс А наследует интерфейс и реализацию класса B, но может ее переопределить. Объекты А можно рассматривать через интерфейс класса B. Класс А зависит от B.
🔸Зависимость: класс А могут затронуть изменения в классе B.
🔸Агрегация: Объект А знает об объекте B и состоит из него. Класс А зависит от B.
🔸Ассоциация: Объект А знает об объекте B. Класс А зависит от B.
🔸Композиция: Объект А знает об объекте B, состоит из него и управляет его жизненным циклом. Класс А зависит от B.
#вопросы_с_собесов #easy
🔸Реализация: класс А определяет методы, объявленные интерфейсом B. Объекты А можно рассматривать через интерфейс B. Класс А зависит от B.
🔸Наследование: класс А наследует интерфейс и реализацию класса B, но может ее переопределить. Объекты А можно рассматривать через интерфейс класса B. Класс А зависит от B.
🔸Зависимость: класс А могут затронуть изменения в классе B.
🔸Агрегация: Объект А знает об объекте B и состоит из него. Класс А зависит от B.
🔸Ассоциация: Объект А знает об объекте B. Класс А зависит от B.
🔸Композиция: Объект А знает об объекте B, состоит из него и управляет его жизненным циклом. Класс А зависит от B.
#вопросы_с_собесов #easy
Предположим, что вы перешли в свой проект, начали работать над несколькими файлами и, возможно, добавили в индекс Git изменения одного из них. Если вы выполните git status, то увидите ваше изменённое состояние.
После чего вы хотите сменить ветку, но пока не хотите фиксировать ваши текущие наработки. Что можно сделать в данном случае?
Команда git stash или git stash push позволяет на время «сдать в архив» (отложить, припрятать) эти изменения в выделенное для этого специальное хранилище.
После выполнения команды вы можете легко переключать ветки и работать в любой, ведь ваши изменения сохранены.
🔸 Посмотреть список отложенных изменений: git stash list
🔸 Применить только что отложенные изменения: git stash apply или git stash apply stash@{2}
#вопросы_с_собесов #easy
После чего вы хотите сменить ветку, но пока не хотите фиксировать ваши текущие наработки. Что можно сделать в данном случае?
#вопросы_с_собесов #easy
Представьте, что вы начали работать над новой фичей в отдельной ветке, после чего другой участник команды добавляет новые коммиты в главную ветку main. Возникает история форков, знакомая каждому, кто использовал Git для совместной работы.
А теперь предположим, что новые коммиты в ветке main затрагивают фичу, над которой вы работаете. Каким способом можно внести изменения из одной ветки в другую?
В Git есть два способа сделать это: слияние или перебазирование.
📌 Способ слияния (merge)
> git checkout feature
> git merge main
➡️или в одну строку: git merge feature main
Эта команда создает в ветке feature новый «коммит слияния», связывающий истории обеих веток. Это отличная неразрушающая операция, при которой существующие ветки никак не изменяются.
Но! Каждый раз, когда вам будет необходимо включить вышестоящие изменения, в ветку feature будет попадать внешний коммит слияния.
Если работа в главной ветке main ведется активно, история вашей ветки feature быстро засорится.
📌 Способ перебазирования (rebase)
Вместо слияния можно выполнить перебазирование ветки feature на ветку main с помощью следующих команд:
> git checkout feature
> git rebase main
В результате вся ветка feature окажется поверх ветки main, включая в себя все новые коммиты в ветке main.
Если вместо команды merge при коммитах используется rebase, эта команда перезаписывает историю проекта, создавая новые коммиты для каждого коммита в исходной ветке.
☑️ Главное преимущество rebase — более чистая история проекта. Эта операция устраняет ненужные коммиты слияния, необходимые для git merge.
#вопросы_с_собесов #easy
А теперь предположим, что новые коммиты в ветке main затрагивают фичу, над которой вы работаете. Каким способом можно внести изменения из одной ветки в другую?
📌
> git checkout feature
> git merge main
➡️или в одну строку: git merge feature main
Эта команда создает в ветке feature новый «коммит слияния», связывающий истории обеих веток. Это отличная неразрушающая операция, при которой существующие ветки никак не изменяются.
Но! Каждый раз, когда вам будет необходимо включить вышестоящие изменения, в ветку feature будет попадать внешний коммит слияния.
Если работа в главной ветке main ведется активно, история вашей ветки feature быстро засорится.
📌
Вместо слияния можно выполнить перебазирование ветки feature на ветку main с помощью следующих команд:
> git checkout feature
> git rebase main
В результате вся ветка feature окажется поверх ветки main, включая в себя все новые коммиты в ветке main.
Если вместо команды merge при коммитах используется rebase, эта команда перезаписывает историю проекта, создавая новые коммиты для каждого коммита в исходной ветке.
☑️
#вопросы_с_собесов #easy
Please open Telegram to view this post
VIEW IN TELEGRAM
#вопросы_с_собесов #easy
В Git можно эффективно отслеживать эволюцию базы кода и вести разработку совместно с коллегами. Но что делать, если необходимо отслеживать огромный репозиторий?
В Git есть две категории больших репозиториев:
1️⃣ В них накапливается очень длинная история
2️⃣ В них находятся огромные двоичные файлы, которые нужно отслеживать и сопоставлять с кодом
🤷♂️ А иногда бывает и то, и другое.
Методы и обходные пути будут разными в каждом сценарии, но в некоторых случаях они могут и дополнять друг друга👇
📌 Клонирование репозиториев с очень длинной историей
1️⃣ Простое решение: поверхностное клонирование git
>
2️⃣ Ювелирная точность
>3️⃣ Альтернатива git shallow-clone: клонирование только одной ветки
>
📌 Управление репозиториями с огромными двоичными файлами
4️⃣ Решение для больших деревьев папок:
5️⃣ Решение для управления обновлением больших файлов: подмодуль Git. Подмодули позволяют вам сохранить один Git-репозиторий, как подкаталог другого Git-репозитория. Это даёт вам возможность клонировать в ваш проект другой репозиторий, но коммиты при этом хранить отдельно.
💡 А еще можно забыть все, что вы прочитали выше, и воспользоваться Git LFS. Это решение, разработанное Atlassian совместно с GitHub в 2015 году.
Расширение Git LFS позволяет хранить в репозитории не сами большие файлы, а только указатели на них. Сами файлы хранятся на удаленном сервере.
В Git можно эффективно отслеживать эволюцию базы кода и вести разработку совместно с коллегами. Но что делать, если необходимо отслеживать огромный репозиторий?
В Git есть две категории больших репозиториев:
Методы и обходные пути будут разными в каждом сценарии, но в некоторых случаях они могут и дополнять друг друга
📌 Клонирование репозиториев с очень длинной историей
>
git clone --depth [глубина] [remote-url]>
git filter-branch --tree-filter 'rm -rf [/путь/к/папке/ненужных/файлов]'
>
git clone [remote_url] --branch [имя_ветки] --single-branch [папка]📌 Управление репозиториями с огромными двоичными файлами
git sparse-checkoutРасширение Git LFS позволяет хранить в репозитории не сами большие файлы, а только указатели на них. Сами файлы хранятся на удаленном сервере.
Please open Telegram to view this post
VIEW IN TELEGRAM
This media is not supported in your browser
VIEW IN TELEGRAM
👶Сетевые протоколы для самых маленьких: наглядная демонстрация от ByteByteGo (Alex Xu)
1️⃣ HTTP
2️⃣ HTTP/3
3️⃣ HTTPS
4️⃣ WebSocket
5️⃣ TCP
6️⃣ UDP
7️⃣ SMTP
#инфографика #easy
1️⃣ HTTP
2️⃣ HTTP/3
3️⃣ HTTPS
4️⃣ WebSocket
5️⃣ TCP
6️⃣ UDP
7️⃣ SMTP
#инфографика #easy