teoretminim.pdf
2.8 MB
Please open Telegram to view this post
VIEW IN TELEGRAM
💘3
Please open Telegram to view this post
VIEW IN TELEGRAM
💘3
Так же, у меня есть лайв канал, где будет публиковаться, посты о моей жизни, и более больше лайв контента.
📎 Ссылка на канал
〰️ 〰️ 〰️ 〰️ 〰️ 〰️ 〰️ 〰️ 〰️ 〰️ 〰️
⭐️ Поддержать
Please open Telegram to view this post
VIEW IN TELEGRAM
Сегодня мы поговорим, на тему коммитов.
Когда-то я и не задумывался о существовании каких-то правил для составления комментариев к коммитам, но потом любознательность взяла верх. Мне казалось, что простых сообщений наподобие «добавлена функция 2», «исправлена ошибка на панели навигации» или просто «foo» вполне достаточно. Однако моя уверенность в том, что комментарии к коммитам, как правило, никто не читает, оказалась ошибкой. Хорошо составленные commit messages очень важны, они помогают нам самим в будущем извлечь максимальную пользу из своих стараний и продуманности.
Коммиты выполняют роль своеобразных кирпичиков в ремесле программиста. При правильном оформлении они и вовсе превращаются в «глазурь» на тортике из вашего кода и приносят значительную пользу. Хорошо написанные комментарии обеспечивают вам правильный контекст.
Хорошие коммиты свидетельствуют об умении человека работать в команде — Питер Хаттерер, Linux.
Распространенная в среде разработчиков ошибка – отношение к Git-репозиторию как к обычному хранилищу резервных копий. Беспорядочные коммиты, фиксирующие текущее состояние кода, могут затруднить восприятие хронологии изменений при последующем изучении кодовой базы. Коммиты типа «WIP», «Ушел на обед», «Хватит на сегодня», «Устал как лошадь», «Всем хороших выходных» и «Я первый»" только засоряют ваш Git-лог, затрудняя понимание существенных правок, поскольку ни одно из этих сообщений не представляет никакой дополнительной ценности.
Никогда не фиксируйте изменения разных файлов по отдельности
Раздельная фиксация изменений для разных файлов может привести к проблемам при просмотре истории коммитов или взаимодействии с другими членами команды. Сложно понять весь контекст изменений и их связь друг с другом.
Например, я работаю над интернет-магазином. Вот чего мне
# Отдельно коммитим изменения в header.js
git add header.js git commit -m "Улучшить верстку header.js"
# Отдельно коммитим изменения в footer.js
git add footer.js
git commit -m "Улучшить дизайн футера"
Таким образом логи очень скоро превратятся в кучу хлама.Коммиты должны быть четкими, лаконичными, организованными в логические блоки. Например, после завершения верстки макета и проработки шапки и футера будет правильнее объединить изменения перед коммитом:
# Фиксируем изменения в header.js и footer.js
git add header.js footer.js
# Коммитим взаимосвязанные изменения вместе
git commit -m "Улучшить UI: обновить header.js и footer.js"
Я понимаю, в теории это выглядит проще, чем будет на деле. Именно поэтому стоит вести приватную ветку специально для фиксации небольших изменений, прежде чем консолидировать их в main посредством объединения.Создание коммита не обязательно означает, что он должен постоянно находиться в бескрайних просторах вашего git-лога. Воспринимайте приватные ветки как персональный скетчпад программиста, где можно свободно экспериментировать, не опасаясь , что кто-то будет пристально следить за вашей работой.
Представьте себе такой сценарий: вы работаете над кодом, и вам нужно отлучиться на небольшой перерыв, или, возможно, вы собираетесь поужинать. Страх потерять текущий прогресс побуждает вас закоммитить изменения — это идеальный пример использования приватной ветки. Неважно, заканчиваете ли вы работу на сегодня или просто хотите сделать спонтанный коммит, эти изменения окажутся в вашей частной ветке.
commit [commit-hash]
Author: Your Name <your.email@example.com>
Date: [Timestamp]
WIP
commit [commit-hash]
Author: Your Name <your.email@example.com>
Date: [Timestamp]
Коммичу на всякий случай
commit [commit-hash]
Author: Your Name <your.email@example.com>
Date: [Timestamp]
Пора на обед
commit [commit-hash]
Author: Your Name <your.email@example.com>
Date: [Timestamp]
Ушел на пописать!Please open Telegram to view this post
VIEW IN TELEGRAM
В условиях совместной работы важно, чтобы именование приватной ветки было очевидным. Ведь нельзя же допустить, чтобы такие коммиты появлялись в публичном поле.
Неважно, как — путем корректного именования или договорившись с коллегами напрямую, сделайте очевидным тот факт, что содержимое этой ветки не предназначено для их глаз. Вот хороший пример названия для приватной ветки:
Каждый коммит, который становится частью вашей публичной ветки, должен представлять собой хорошо продуманную, самодостаточную, обратимую и четко описанную единицу работы.
✅ Как сделать логи более читаемыми
Начните со смены рабочей ветки:
7 стандартных правил написания идеального комментария к коммиту
Приведенные здесь правила содержат рекомендации и лучшие практики для обеспечения правильного форматирования комментариев и донесения информации в понятном виде. Разные правила могут содержать разночтения в части написания текста/темы коммита, однако их конечная цель состоит в улучшении читабельности и понятности комментариев к коммитам в системе контроля версий Git.
Правило 1: Ограничьте тему до 50 символов
При формировании темы коммита рекомендуется придерживаться краткости и фокусировки на главном. Строка темы служит кратким изложением цели коммита и в идеале не должна превышать 50 символов.
Если вы не можете уложиться в 50-символьный лимит, это может свидетельствовать о том, что цель коммита не сформулирована. Между тем, коммиты должны быть ясными, краткими и самодостаточными. Придерживаясь этого правила, вы вынуждены будете выделять лишь наиболее важную информацию, что позволит вашей команде и вам самим с первого взгляда понять суть изменений.
Правило 2: Пишите с заглавной буквы только первую букву темы
При составлении комментария оставьте только одну заглавную букву — с нее должна начинаться тема. Остальную часть сообщения, включая все дополнительные сведения, оставьте в нижнем регистре.
Правило 3: Не ставьте точку в конце темы
Причина, по которой в строке темы не ставится точка, отчасти имеет исторические корни, а отчасти заключается в сохранении единого стиля. Принято рассматривать строку темы как заголовок или команду, поэтому она пишется в повелительном наклонении (например, «Добавить функцию или «Исправить ошибку», а не «Добавлена функция» или «Исправлена ошибка»). Отсутствие точки в конце помогает соблюсти это правило и сохранить лаконичность.
Это правило может показаться странным, но оно основано на практической целесообразности. Многие разработчики используют для работы с Git интерфейсы командной строки, в которых часто отсутствует автоматическое форматирование. Поэтому для обеспечения единообразия и разборчивости комментариев были введены специальные правила оформления коммитов.
Важно пояснить, что важность соблюдение этого правила обусловлена тем, что пользователи командной строки могут столкнуться с усечением текста в строке длиннее 72 символов.
В большинстве случаев длина ваших комментариев будет превышать 72 символа. В таких случаях рекомендуется разрывать текст и писать продолжение на следующей строке, как показано в приведенном ниже комментарии:
Неважно, как — путем корректного именования или договорившись с коллегами напрямую, сделайте очевидным тот факт, что содержимое этой ветки не предназначено для их глаз. Вот хороший пример названия для приватной ветки:
private/do-not-use-this.Каждый коммит, который становится частью вашей публичной ветки, должен представлять собой хорошо продуманную, самодостаточную, обратимую и четко описанную единицу работы.
Начните со смены рабочей ветки:
git checkout feature/cart-section
Затем объедините все коммиты из вашей ветки private/do-not-use-this в feature/cart-section с помощью единого коммита:git merge - squash private/do-not-use-this
После слияния необходимо составить ясный и содержательный комментарий:# Напишите качественный комментарий
git commit -v -m "Фича: Разработать корзину с анимацией при оформлении заказа
обновлены CSS корзины, исправлены ошибки в выравнивании текста, верстка изменена для улучшения внешнего вида и читаемости"7 стандартных правил написания идеального комментария к коммиту
Приведенные здесь правила содержат рекомендации и лучшие практики для обеспечения правильного форматирования комментариев и донесения информации в понятном виде. Разные правила могут содержать разночтения в части написания текста/темы коммита, однако их конечная цель состоит в улучшении читабельности и понятности комментариев к коммитам в системе контроля версий Git.
Правило 1: Ограничьте тему до 50 символов
При формировании темы коммита рекомендуется придерживаться краткости и фокусировки на главном. Строка темы служит кратким изложением цели коммита и в идеале не должна превышать 50 символов.
Если вы не можете уложиться в 50-символьный лимит, это может свидетельствовать о том, что цель коммита не сформулирована. Между тем, коммиты должны быть ясными, краткими и самодостаточными. Придерживаясь этого правила, вы вынуждены будете выделять лишь наиболее важную информацию, что позволит вашей команде и вам самим с первого взгляда понять суть изменений.
Правило 2: Пишите с заглавной буквы только первую букву темы
При составлении комментария оставьте только одну заглавную букву — с нее должна начинаться тема. Остальную часть сообщения, включая все дополнительные сведения, оставьте в нижнем регистре.
Правило 3: Не ставьте точку в конце темы
Причина, по которой в строке темы не ставится точка, отчасти имеет исторические корни, а отчасти заключается в сохранении единого стиля. Принято рассматривать строку темы как заголовок или команду, поэтому она пишется в повелительном наклонении (например, «Добавить функцию или «Исправить ошибку», а не «Добавлена функция» или «Исправлена ошибка»). Отсутствие точки в конце помогает соблюсти это правило и сохранить лаконичность.
git commit -v -m "Создать функциональность корзины с анимацией"
Правило 4: Оставьте между темой и телом комментария пустую строкуЭто правило может показаться странным, но оно основано на практической целесообразности. Многие разработчики используют для работы с Git интерфейсы командной строки, в которых часто отсутствует автоматическое форматирование. Поэтому для обеспечения единообразия и разборчивости комментариев были введены специальные правила оформления коммитов.
git commit -v -m "Создать функциональность корзины с анимацией
тело комментария...
"
Правило 5: В теле комментария нельзя писать больше 72 символов в одной строкеВажно пояснить, что важность соблюдение этого правила обусловлена тем, что пользователи командной строки могут столкнуться с усечением текста в строке длиннее 72 символов.
В большинстве случаев длина ваших комментариев будет превышать 72 символа. В таких случаях рекомендуется разрывать текст и писать продолжение на следующей строке, как показано в приведенном ниже комментарии:
git commit -v -m "Создать функциональность корзины с анимацией
улучшены CSS раздела "Корзина", устранены проблемы с выравниванием текста, доработан дизайнPlease open Telegram to view this post
VIEW IN TELEGRAM
для улучшения внешнего вида
и читабельности."
В заключение отмечу, что стандартной практикой обозначения маркированных пунктов списков является использование дефиса или звездочки с пробелом.Правило 6: Используйте повелительное наклонение
Очень полезно составлять комментарии с оглядкой на то, что при выполнении коммита будет выполнено определенное действие. Постройте комментарий таким образом, чтобы он логически завершал предложение «Применение коммита позволит...».
Например, вместо
git commit -m "Исправлены баги в верстке" ❌, используйте следующее git commit -m "Исправить баги в верстке" ✔.То есть, если применить этот коммит, он действительно позволит исправить ошибку на странице макета.
Правило 7: Объясняйте «Что» и «Почему», а не «Как»
Если ограничить смысловую нагрузку комментария вопросами «что сделано?» и «почему сделано?», получится краткое, но информативное объяснение каждого изменения. Разработчики, которым интересно, как был реализован код, могут обратиться непосредственно к кодовой базе. Поэтому подчеркните, что именно было изменено и каковы причины этого изменения. И не забудьте упомянуть, какой компонент или участок кода были затронуты.
Правило 7: Объясняйте «Что» и «Почему», а не «Как»
Если ограничить смысловую нагрузку комментария вопросами «что сделано?» и «почему сделано?», получится краткое, но информативное объяснение каждого изменения. Разработчики, которым интересно, как был реализован код, могут обратиться непосредственно к кодовой базе. Поэтому подчеркните, что именно было изменено и каковы причины этого изменения. И не забудьте упомянуть, какой компонент или участок кода были затронуты.
Angular является ярким примером эффективного применения комментариев. Команда разработки придерживается специальных префиксов, таких как "chore: , "docs: ," "style: ," "feat: ," "fix: , "refactor: ," и "test: ." Благодаря включению этих префиксов в тему коммита, беглого взгляда на историю достаточно, чтобы понять, какие изменения производились в коде.
Не забывайте, что главным приоритетом является обеспечение прозрачности и осмысленности каждого коммита. Хорошо составленный комментарий выполняет роль исторического документа, объясняющего «что, «почему», но не «как» было сделано в проекте. Помните, что история коммитов — это средство организации эффективной совместной работы. Возьмите за правило создавать информативные, краткие и последовательные комментарии.
• https://git-scm.com/doc
• https://git-scm.com/book/en/v2
• https://lab.github.com/
• https://www.atlassian.com/git/tutorials
• https://learngitbranching.js.org/
• https://www.gitkraken.com/git-cheat-sheet
• https://www.git-tower.com/learn/
Please open Telegram to view this post
VIEW IN TELEGRAM
❤1
Сегодня мы с вами затронем тему «Криптография в теории»
Криптография - это наука о методах защиты информации от несанкционированного доступа. Она включает в себя разработку алгоритмов шифрования и дешифрования, создание криптосистем, обеспечивающих конфиденциальность данных и целостность информации.
Основные принципы криптографии включают:
1. Симметричное шифрование: При использовании симметричных алгоритмов отправитель и получатель используют один и тот же ключ для шифрования и расшифрования сообщений. Примерами таких алгоритмов являются AES (Advanced Encryption Standard) и DES (Data Encryption Standard).
2. Асимметричное шифрование: В асимметричной криптографии используются два различных ключа - открытый (для шифрования) и закрытый (для расшифрования). Это позволяет безопасно обменяться данными между сторонами без необходимости предварительного обмена ключами. Примеры таких алгоритмов - RSA, ECC.
3. Хэш-кодирование: Хеш-кодирование используется для создания уникального "отпечатка" блока данных с помощью хэш-функций, таких как SHA-256 или MD5. Хеш-коды часто применяются для проверки целостности данных.
4. Цифровые подписи: Цифровая подпись - это метод проверки авторства сообщения или документа с использованием открытого ключа отправителя. Это обеспечивает подлинность информации и невозможность ее изменения после подписи.
5. Эллиптическая криптография: Основанная на математических концепциях эллиптических кривых, эта форма криптографии позволяет создавать более компактные ключи при сохранении высокого уровня безопасности.
6. Квантовая криптография: Использует свойства квантовой механики для защиты информации от перехвата или подслушивания при передаче через открытыми средами.
Кроме того, важными понятиями в криптографии являются аутентификация, конфиденциальность, целостность данных и невозможность отказаться от действий (non-repudiation). Комбинация различных методов шифрования позволяет создавать надежные системы защиты информации в различных областях: банковское дело, здравоохранение, интернет-безопасность и другие.
Всем хороших выходных!
Можете ниже в комментариях поделиться, как у вас проходят выходные.
Please open Telegram to view this post
VIEW IN TELEGRAM
Логово кодера 🧑🏼💻
Так же, у меня есть лайв канал, где будет публиковаться, посты о моей жизни, и более больше лайв контента. 📎 Ссылка на канал 〰️ 〰️ 〰️ 〰️ 〰️ 〰️ 〰️ 〰️ 〰️ 〰️ 〰️ ⭐️ Поддержать
Уже на лайв канале новый пост! 😳
Please open Telegram to view this post
VIEW IN TELEGRAM
Всем привет! 👋
Давно уже с вами не выходил на связь. не хотите ли стримы по программированию, где мы с вами будем разрабатывать? И что вы бы хотели, чтобы мы на стримах разрабатывали?👀
Давно уже с вами не выходил на связь. не хотите ли стримы по программированию, где мы с вами будем разрабатывать? И что вы бы хотели, чтобы мы на стримах разрабатывали?
Please open Telegram to view this post
VIEW IN TELEGRAM
Цель проекта
Основной целью нового кейса является улучшение пользовательского опыта путем создания эффективной системы общения через чат. Использование Telegram-бота позволяет автоматизировать ответы на сообщения пользователей и организовать структурированные дискуссии по различным темам.
Используемые инструменты
WebSockets: этот протокол обеспечивает двустороннюю связь между фронтендом и бэкендом для передачи данных в реальном времени, что позволяет достичь высокой отзывчивости приложения.
Grammy JS: фреймворк на базе JavaScript для разработки функционала Telegram-ботов, который предоставляет гибкие возможности по созданию логики ответов на сообщения.
BullMQ: расширение очередей задач Redis, которое обеспечивает надежное управление задачами в асинхронном режиме, что способствует оптимизации процессов обработки запросов.
Redis: высокопроизводительная база данных ключ-значение, используемая для хранения информации о пользователях, сообщениях и текущих дискуссиях (тредах).
Процесс работы
Установка WebSockets: начало процесса заключается в настройке соединения через WebSockets между фронтендом и бэкендом для обмена данными в режиме реального времени.
Разработка функционала бота: с использованием Grammy JS создается логика ответов от Telegram-бота на сообщения из бесед по различным темам (тредам), что способствует повышению интерактивности приложения.
Организация очереди задач: BullMQ используется для эффективного управления задачами, что помогает распределить нагрузку на сервер и повысить производительность системы.
Интеграция Redis: подключение Redis к приложению позволяет хранить информацию о пользователях, сообщениях и текущих дискуссиях (тредах) с высокой скоростью доступа.
Преимущества нового подхода
Автоматизированные ответы в чатах значительно улучшат пользовательский опыт.
Организация структурированных дискуссий по многообразным темам способствует более быстрому нахождению пользователями необходимой информации, повышая уровень обслуживания и удовлетворенность клиентов.
Эффективное управление задачами посредством очереди позволяет оптимизировать процессы обработки запросов и увеличить отзывчивость системы.
Надежное хранение данных о пользователях, сообщениях и дискуссиях в Redis обеспечивает быстрый доступ к информации и предотвращает возможную потерю данных.
Внедрение нового кейса микросервиса чата с интеграцией Telegram-бота и работой с тредами представляет собой важный шаг в развитии коммуникационных возможностей приложения. Использование передовых технологий, таких как WebSockets, Grammy JS, BullMQ и Redis, не только повышает эффективность работы системы, но и улучшает пользовательский опыт. Благодаря автоматизированным ответам, организации структурированных дискуссий и эффективному управлению задачами, новый функционал чата значительно расширяет возможности приложения и способствует созданию более привлекательной пользовательской среды.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤3🥰2💘2
Please open Telegram to view this post
VIEW IN TELEGRAM
Логово кодера 🧑🏼💻
Всем привет! 👋 Давно уже с вами не выходил на связь. не хотите ли стримы по программированию, где мы с вами будем разрабатывать? И что вы бы хотели, чтобы мы на стримах разрабатывали? 👀
Please open Telegram to view this post
VIEW IN TELEGRAM
🤝3
Слепой метод набора — способ эффективно набирать текст десятью пальцами не глядя на клавиатуру. Слепой набор позволяет не думать о процессе печати и сосредоточиться на тексте и своих мыслях. Также:
• Хорошая техника позволяет сократить количество ошибок
• С опытом скорость набора текста станет выше
• При необходимости достаточно легко учатся новые алфавиты
Как это работает?
Слепой набор включает в себя несколько важных компонентов:
Постановка рук. Выпирающие полоски на клавишах F и J — это специальные метки, показывающие место для указательных пальцев в состоянии покоя. Постановка рук — это первое с чего начинают практику слепого набора.
Набор. В слепом наборе у каждого пальца есть своя зона на клавиатуре. Только соответствующий палец может нажимать клавиши своей зоны. Это особенно сложное ограничение для тех, кто уже постоянно и активно печатает, так как требует от человека изменения привычек.
К сожалению, стандартные клавиатуры сделаны так, что большая нагрузка выпадает на мизинцы, особенно на правый мизинец у программистов. У эргономичных клавиатур управляющие клавиши часто выносят под большие пальцы, так как они недозагружены и, в целом, более сильные и подвижные по сравнению с мизинцами.
Наиболее эффективный набор в слепом режиме происходит когда пальцы постоянно чередуются. Попробуйте проверить это сами. Наберите слово "папа" указательным пальцем левой руки (эти буквы находятся в его зоне), а затем слово "гага" (указательные пальцы обоих рук).
Большинство раскладок проектировалось с учетом этого фактора, например, раскладка ЙЦУКЕН. А вот QWERTY создавалась слишком давно, когда приходилось учитывать другие факторы (например, залипание клавиш), и это отразилось на эффективности. Поэтому были созданы альтернативные раскладки, такие как DVORAK и Colemak. Вот что написано в Википедии по поводу последней:
• Скорость. Быстрее QWERTY и несколько быстрее Дворака, так как в Colemak разгружены мизинцы и чаще применяется чередование рук.
• Эргономичность. 10 наиболее распространённых букв английского языка и клавиша Backspace расположены на втором (домашнем) ряду клавиатуры. В Colemak домашний ряд используется в среднем на 3 % чаще, чем в раскладке Дворака, и 40 % чаще, чем в QWERTY. Благодаря этому при печати на Colemak пальцам приходится меньше перемещаться, чем при печати на QWERTY.
Но чередование — это не только раскладка, но и техника. Пробел лежит сразу под двумя большими пальцами, а значит у нас есть выбор пальца для нажатия. В слепой печати пробел должен нажиматься большим пальцем той руки, которая не была задействована в нажатии предыдущего символа. Например, если мы набираем слово "код", то пробел после него нажимается левой рукой, если слово "моя", то правой.
Как научиться?
Можно и самостоятельно, просто следуя правилам выше. Но с большой долей вероятности процент ошибок во время набора будет высок, и в процессе обучения, и после. Специализированные сервисы помогают учиться печатать с минимальным числом ошибок. Подобных сервисов много, и вам стоит найти их в Гугле и попробовать разные варианты (в комментариях ниже читатели делятся ссылками).
Основным препятствием является не столько отсутствие времени на обучение, сколько работа, связанная с набором текста. Так как в этом случае для быстрого печатания приходится делать это привычным способом. Главное после некоторой практики на тренажерах заставить себя полностью отказаться от набора старым способом и нажимать клавиши только теми пальцами, которыми того требует слепой набор. Причем совершенно нормально, если вы будете подсматривать на клавиатуру. Техника заключается не в том, чтобы не смотреть, а в том, чтобы правильно перемещаться по клавиатуре. Со временем необходимость смотреть отпадет. И да, скорость при этом упадет катастрофически, но не волнуйтесь, восстановится она очень быстро, уже через пару недель вы, вероятно, догоните себя прежнего, а затем начнете двигаться вперед.
Please open Telegram to view this post
VIEW IN TELEGRAM