torinasakura / jumpeebunee.github.io Goto Github PK

View Code? Open in Web Editor NEW

0.0 0.0 0.0 47.35 MB

License: BSD 3-Clause "New" or "Revised" License

Shell 1.86% TypeScript 98.14%

jumpeebunee.github.io's Introduction

jumpeebunee.github.io's People

Contributors

Watchers

jumpeebunee.github.io's Issues

Знакомство с Typescript

С чем связан запрос на фичу?

Ознакомиться с азами работы с языками программирования на примере TypeScript, научиться покрывать простые кейсы по автоматизации задач с помощью ЯП и выполнить задание

Расскажите как вы это себе видите

План

Переменные и типы данных
Структуры данных
Условия
Циклы
Функции
Работа с ошибками
База Advanced JS API (методы массивов)

Задание

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

Должны присутствовать функции для регистрации:
login(username, password) - вход
logout() - выход
register(username, password) - регистрация
whoami() - получение авторизованного на данный момент пользователя (сессии)
При регистрации должна быть проверка: логин должен быть не короче 5 символов, пароль должен быть не короче 6. Если условие не выполняется - выбрасывать ошибку
Должна быть возможность хранить креды (credentials) для нескольких пользователей
При попытке сделать логаут без активной сессии - должна выбрасываться ошибка
При попытке сделать whoami без активной сессии - выбрасывать ошибку
При удачном вызове whoami в консоли должен быть вывод логина пользователя, который авторизован в данный момент
При попытке сделать регистрацию/логин в момент, когда уже есть активная сессия - выбрасывать ошибку
Все данные должны быть типизированы: аргументы функций, используемые переменные, возвращаемые функциями значения

Требования к обработке ошибок:

Ошибки (и код в целом) не должны содержать символов кириллицы, при этом в некоторых ошибках должны использоваться шаблонные строки. Пример:

User with login Dassfgfd not found

Password for user Johnathan is incorrect

Требования к оформлению задания

Задание должно быть выполнено в отдельной ветке. К этой ветке должен быть создан pull request. Если pull request еще не готов к мержу в мастер - он должен быть помечен как draft. Код должен удовлетворять проверкам lint и typecheck (yarn lint, yarn typecheck)

Приложите пример реализаций

No response

Миграция на систему плагинов atls/tools

Какого рода задача?

Мигрировать авторизацию на tools

Что и где будем менять?

Для сборки приложения необходимо использовать yarn service build, для запуска в дев режиме - yarn service dev

Необходимо оформить файл auth как пакет (воркспейс) с определенной структурой: директория src и index.ts внутри - пример

Внутри package.json должны находится скрипты для запуска проекта - build, dev и start

build билдит проект через yarn service build и кладет js в папку dist
dev запускает проект в dev режиме
start запускает уже сбилженный проект (node dist/index.js)

Краткий обзор tools

Укажите референс

Приведение проекта к общему стеку

Пример приложения, собирающегося с помощью yarn service - https://github.com/atls/project-starter/blob/master/gateway/entrypoints/public/package.json

Пример библиотеки, которая будет публиковаться в npm регистр - https://github.com/atls/nextjs/blob/master/packages/next-sitemap-generator/package.json

Правила работы с GitHub

Для более эффективной работы, мы в своей команде используем Github. Для нас GitHub это место где находится вся необходимая информация для работы и место где находится истина — код.

Github в нашей команде используют все: разработчики, дизайнеры, менеджеры, заказчики и все все все. Все находятся в одной среде и все всё видят. И это прекрасно. Но для того чтобы использовать GitHub эффективно, к нему надо привыкнуть и его надо освоить.

В этом кратком руководстве, мы собрали собственные командные практики работы с GitHub. Также здесь есть ссылки на официальные руководства GitHub для расширения кругозора.

Работа с Issues

Issues — это место где мы обсуждаем всю важную работу, от начала (создание issue) и до конца (закрытие issue).

Важно чтобы обсуждение по той или иной задаче/проблеме проходило внутри Issue. Это позволяет отследить историю в случае возникновения такой проблемы, а также даёт возможность просто делиться ссылкой на Issue или конкретный комментарий внутри Issue.

Об Issues на GitHub Docs

Issue Labels

Сам по себе Issue не несёт никакого «смыслового окраса». Для этого, мы применяем лейблы.

Например:

Issue с лейблом documents — это задача или проблема, которая относится к документации
Issue с лейблом feature — означает что там лежит какая-то информация о фиче
Issue с лейблом bug, ну ты понял

Поэтому очень желательно, чтобы Issues не оставались без лейблов. Список доступных лейблов доступен с правой стороны Issue, заголовок Labels:

Управление Лейблами на GitHub Docs

Отдельно про Markdown

Markdown — это облегчённый язык разметки. Эта разметка позволяет сделать текст жирным или наклонным (италик).

Делать удобные для отображения списки:

Раз
Два
Три

А также цитировать своих собеседников:

Привет! Всё готово к релизу, погнали?

Чел, сегодня пятница, какой релиз :|

Весь этот набор разметки, позволяет сделать самое главное: писать красивые и чётко сформулированные мысли в текстовом виде.

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

Поэтому важно ознакомиться с Основным синтаксисом письма и форматирования Markdown на GitHub Docs. Там же есть секция с продвинутыми практиками.

Работа с Branches

Именование веток

Именовать ветки тоже необходимо в соответствии с характером ваших изменений:

<характер изменений>/<2-3 слова об изменениях>

характер изменений - берется из conventional commits (feat, chore, fix, refactor и тд)

Примеры:

feat/about-fragment
fix/index-page-error
refactor/project-structure

Работа с Pull Request

Pull Requests позволяют вам сообщить другим об изменениях, которые вы внесли в ветку в репозитории на GitHub. После открытия Pull Request'а вы можете обсудить и просмотреть потенциальные изменения с коллегами и добавить последующие коммиты до того, как ваши изменения будут объединены в базовую ветку.

Из документации к Pull Request'ам на GitHub Docs

Как создавать?

Создание Pull Request'а на Github Docs

Когда создавать?

Можно сразу после первых коммитов. Ежедневно, к концу рабочего дня должно коммититься текущее состояние вашей ветки. Если пр не готов к ревью - он отправляется в драфт (также по этой причине нет смысла использовать WIP в коммит месседжах: если работа в процессе - пр находится в драфте)

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

В будущем такой подход также помогает при навигации по истории коммитов.

Кого ставить в assignee?

Указываем себя, как автора. Это позволит потом по PR делать фильтрацию и получает предсказуемые результаты.

Кого указывать в ревьюверах?

Лида (ментора) или если таковой отсутствует - @TorinAsakura

Что за статусы проверок?

У проектов могут быть настроены проверки проектов, которые выполняются при создании и обновлении Pull Request'а. В них можно получить всю необходимую информацию о выполнении тестов.

Можно ли форсить ветку? (Нужна ли эта секция? Не слишком всё усложняет на данном этапе?)

Можно, но только если от этого больше пользы, чем вреда. Когда можно:

Когда ревью еще не провели.
Когда в ветку еще ничего не вливали (обновленный dev)
Когда PR на этой ветке еще нет.

Когда нельзя:

Когда ревью провели. Комментарии привязываются к хешу коммитов. Если форснуть, то это уже новые коммиты, даже если в них ничего не менялось. Из-за этого весь прогресс ревью тупо слетает. В итоге ревьюверу нужно потратить время, чтобы определиться, где он оставлял ревью, а где нет.
Когда форсом можно ненароком ввести в заблуждение. После форса достаточно муторно посмотреть, что же в итоге изменилось. Можно, конечно, выдрать хеши и пойти в diff, чтобы посмотреть, что изменилось.

Лучше пусть будут лишние коммиты (коммиты лишними не бывают), так процесс выглядит более прозрачным и последовательным.

Conventional Commits или Соглашение о коммитах

«Соглашение о коммитах» — простое соглашение о том, как нужно писать сообщения коммитов. Оно описывает простой набор правил для создания понятной истории коммитов, а также позволяет проще разрабатывать инструменты автоматизации, основанные на истории коммитов.

Цитата из официального документа соглашения

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

Важно! Никакой кириллицы ни в коде, ни в комментариях к коммитам, ни в названиях бранчей быть не должно

Post Scriptum

Эффективная работа в GitHub для нас очень важна. Здесь протекает вся рабочая «жизнь» проектов над которыми мы работаем. Поэтому для нас важно, чтобы каждый соблюдал базовые правила работы с этим инструментом.

Вообще, у GitHub довольно обширная и полезная документация, с которой рекомендуется ознакомиться.

Если незнаком или мало опыта с Git, то вот полезный тур на русском языке по нему. Чёрт побери, Git!?! быстрая и понятная подсказка по Git'у. Или Интерактивная визуализация и учебник по Git.

Нормы общения и взаимодействия в команде

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

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

Как вести обсуждение в Issue, Чатах, Войсчатах

Что бы обсуждение было наиболее эффективным, следует соблюдать несколько простых правил и рекомендаций.

Используй цитирование

В Github не предусмотрена система тредов внутри Issue из-за этого в обсуждениях может происходить путаница.

Что бы не запутаться мы используем инструмент цитирования — ">".

Это позволяет сохранять нить обсуждения и «не распыляться» в обсуждении.

Пиши грамотно

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

Если сделал ошибку в своём сообщении и позже её заметил, поправь. В GitHub есть редактирование.

Старайся четко формулировать вопросы и мысли

Важнейшее правило. От этого будет зависеть качество ответа на твой вопрос или качество обсуждения твоей идеи или предложения.

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

Вот некоторые рекомендации по теме:

Используй Markdown

В дополнении к предыдущему пункту, советуем освоить Markdown. Он позволит твоей мысли быть четкой, ясной и понятной. Такой текст легче воспринимать, а взаимодействовать с тобой приятней и проще.

Сдерживай себя

Если хочется едко (или как говорят — токсично) пошутить в чей-либо адрес. Либо сделать едкое замечание. Процесс совместной работы тоже труд. А как известно труд нужно уважать. Поэтому едкости и токсичности здесь не место.

Если очень хочется пошутить — это можно сделать в чате или в личном разговоре, GitHub - для дел и работы.

Другие важные рекомендации

Асинхронность в работе

Простой пример из рабочих будней:

У тебя есть задача: [feature] Bankcard Template — примерное время решения 4-6 часов
Рядом другая задача: [question] Deploy to GKE — примерное время на поиск ответа до 2 часов

Ответить на вопрос быстрее и он позволит запустить в работу ещё одну задачу и займёт это на порядок меньше времени чем разработка шаблона для банковских карт.

Иными словами – запускай решение задач, которые не требует твоего постоянного присутствия, чтобы они ждали в очереди.

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

Если испытываешь сложности, зови на помощь

Очень часто, попросить помощи в какой-то части работы намного проще, а самое главное быстрее, чем пытаться решить её самостоятельно. Многие новички так делают и это плохо. Намного эффективней попросить помощи и решить проблему быстрее. Ты сэкономишь своё время и как ни странно чужое. Profit!

Не бойся задавать вопросы

Особенно если ты новичок. Или не новичок. Лучше задать вопрос, даже если он кажется глупым (как правило это не так), чем не задать. Один не заданный во время вопрос, может обернуться комом проблем в будущем. Как правило это впустую потраченное время из-за банального недопонимания проблемы или задачи.

Поэтому лучше спросить, а если не уверен переспросить.

Если выполняешь задачу совместно с коллегой

Кооперируйтесь, созванивайтесь, обсуждайте проблемы и задачи. Но самое главное — документируйте итоги своих взаимодействий. Иначе говоря, если вы созвонились и договорились о чём-то, зафиксируйте итог созвона в issue.

Как правило хватает одного списка, описанного тезисно.

Все обсуждения по работе ведутся строго в рабочих инструментах

Github, Discord, Рабочие каналы Telegram. Лучше всего, когда бо́льшая часть информации оседает в Issue.

Отписывайся в дейлик после его создания

Дейлик, он же Daily Standup Meeting — это настроенный репозиторий, в котором каждый день утром создаётся issue. А вечером этот issue закрывается.

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

Дейлик нужен для всеобщего понимания того, кто чем занят сегодня и над какой задачей трудится. А также над отслеживанием сложностей у коллег.

Шаблон того, как надо писать в теле issue дейлика.

Находи время развиваться

Работа разработчика, инженера, дизайнера, менеджера и любого другого человека в IT сфере, не может обходиться без постоянного самообучения. Иначе есть риск «остаться в прошлом». Поэтому находи время развиваться.

Читай тематические каналы и ресурсы. Конечно же у тебя должен быть аккаунт на Хабре :)

Находи время на перерывы

Удалённая работа — это сидение перед экраном часами. Это не очень хорошо для здоровья. Поэтому находи время на перерывы.

Landing - First Step

Задача

Реализация первого этапа учебного проекта на базе проекта Академии