🔄 ♻️ Работаем с командами Git

Помню, мне доводилось деплоить в продакшен, а потом срочно откатывать изменения из-за того, что прод прилёг отдохнуть🏖. Это было 3 года назад, когда я работал менеджером ИТ-проектов.

😎 Не будем ограничиваться веб-мордами хостингов кода и изучим Git-команды. Попробуем отправить код из Anaconda Cloud в GitHub-репозиторий! По итогу, получим практическое представление о работе с Git.

➕ Предусловия:

0⃣ Регистрируемся на GitHub. Создаем репозиторий. Грузим туда файлы с кодом. Достаточно будет файла test.py с кодом print("Hello world")

1⃣ Регистрируемся на Anaconda.com. Заходим на Jupyter Notebook.

➕ Начинаем изучать команды Git:

2⃣ Прежде всего, склонируем GitHub-репозиторий в Анаконду, используя HTTP.

Открываем "New Launcher" (Ctrl + Shift + L). Далее Terminal. В терминале вводим команду:
git clone {HTTP-ссылка на репу}

В конце ссылки можно добавить .git

Далее заходим в склонированный репозиторий:
cd {название репы}

3⃣ Создаем новую ветку в которой будем вести разработку, и сразу на нее переключаемся:
git checkout -b {название ветки: test, feature и т.п.}

Например: git checkout -b feature

4⃣ Колдуем. Вносим правки в код:
Было: print("Hello world")
Стало: print("Хочу 300k/сек")

5⃣ Проверим изменения:
git status

6⃣ Добавляем файлы в индекс (stage area). Это промежуточная область между рабочим каталогом (где делаем изменения в файлах) и репозиторием. Индекс позволяет выбирать какие файлы отправить в коммит.

🔸 Добавить все измененные файлы (вводить с точкой):
git add .

🔸 Добавить конкретный файл:
git add {название файла вместе с его расширением}

7⃣ Создаём коммит (сохранение изменений). Флаг -m означает message. Можно написать пояснение:
git commit -m "Пофиксил баги, надеюсь новых не добавил"

8⃣ Отправляем нашу ветку в репу на GitHub:
git push origin {название ветки}

В нашем случае: git push origin feature

origin — это имя, которое по умолчанию присваивается нашему удаленному репозиторию на GitHub.

9⃣ Проходим аутентификацию.
Вводим свой username, а для password вводим классический токен.
Создается токен по ссылке.

1⃣ 0⃣ Идем на GitHub, открываем репозиторий и видим таб "2 Branches". Кликаем.
Видим, что помимо main, появилась и наша новая ветка.
Заходим в нее, заходим в отредактированный файл и видим изменения: print("Хочу 300k/сек")
Делаем pull request (запрос на внедрение кода) из интерфейса, затем мержим в main.
___
😎 Понравился пост? Подписывайся, чтобы не пропустить следующие!

Артем Лещев

📋 «Доброе начало — полдела откачало». Мой чек-лист передачи проекта от сейлз-менеджера к руководителю проекта.

Участвую в конкурсе «Продолжи мысль» от @systems_education

Данный пост — мой полевой опыт. В 2022-2023 гг. я работал руководителем ИТ-проектов в смоленской веб-студии, где одновременно вел несколько проектов. Затем происходила ситуация как на картинке.

В один день встал вопрос: как мне эффективно получать от менеджера по продажам (далее — сейлз) информацию о новом проекте? Иными словами — мне нужен был качественный онбординг в проект. Я придумал как его организовать.

🔴 AS-IS.
Сейлз набрасывал концептуальную структуру проекта, затем голосом вводил меня в курс дела.

Очевидно, что устная информация запоминалась плохо; перемешивалась с другими проектами; к ней нельзя было обратиться в дальнейшем, если что-то забудешь; да и сам сейлз мог что-то забыть сказать.

🟢 TO-BE.
Я составил чек-лист, по которому сейлз максимально подробно описывал для меня проект. Всего было 5 разделов:

1. Описание проекта в свободной форме

Здесь сейлз своими словами заполнял следующую информацию:

(а) Давал контакты для связи с ЛПР.

(б) Давал характеристику ЛПР.

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

(в) Описывал текстом бизнес-цели и пользовательские цели проекта.

(г) Давал текстовые комментарии к концептуальной структуре проекта.

(д) Давал текстовое описание к референсам, которые обсуждал с клиентом. Что конкретно понравилось на каждой веб-морде.

(е) Отдельным пунктом я просил описать те референсы, которые поступили от самого заказчика.

2. Какой функционал главный?

Как говорил Павел Дуров: «Самое главное — уметь отличать самое главное». Сейлз мне расписывал что у клиента "болит" сильнее всего, в плане функциональных требований.

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

3. Что уже 100% определено и согласовано?

Список договоренностей, которые не подлежат сомнению. Видя их перед глазами, я мог полноценно сконцентрироваться на 4-м пункте.

4. Что еще предстоит уточнить и согласовывать?

Список вопросов и проблем, которые стоит обсудить и решить на моем первом установочном созвоне с ЛПР, а также по ходу реализации проекта в целом.

5. Какое у сейлза субъективное мнение о проекте?

Совершенно очевидно, что заключив договор, у сейлза уже сложилось какое-то представление с чем мы имеем дело, и что планируем положить в портфолио. Фактически, это резюмирование всех вышеназванных пунктов.

📈 ИТОГ (4 пункта).

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

Отсутствие документации на проекте – всегда боль. Ондорбинг в проект стал структурированнее и понятнее.

2. Устное обсуждение с сейлзом стало существенно более структурированным.

Отмечу, что на раннем этапе стали вскрываться неучтенки. Ведь данный чек-лист — словно собственное ретро для сейлза; медитация; возможность обдумать проект после заключения договора. Как частно бывает, умные мысли приходят уже после того, как некое событие случилось.

3. Я настоял на том, чтобы сейлз организовывал совместный созвон с заказчиком.

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

4. Повысилось качество проработки требований и написания ТЗ.

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

Как гласит пословица: "Доброе начало – полдела откачало". Благодаря чек-листу я четко знал какие задавать вопросы ЛПРу; как подступиться к написанию ТЗ; что выносить на обсуждение с программистами.

💬 Диалоги со всеми заинтересованными лицами стали легче направляться в конструктивный ряд.

#продолжи_мысль_SE #Менеджмент #Требования

Артем Лещев

😄 С днем знаний!

Я закончил школу 10 лет назад и даже не думал, что буду работать в ИТ. Сам по образованию историк и могу преподавать в колледже.

У меня было 2 учительницы информатики. У каждой был свой подход к преподаванию:

😁 У первой (до 9 класса) мы играли в CS, подставляли наши фотки вместо Марио в эмуляторе Денди, и просто взламывали Пентангон залипали в телефон.

🐧 У второй (10-11) мы записывали определения терминов: что такое "информация", что такое "данные"... Ни о каком программировании на Python, как учат школьников сейчас, даже речи не шло. Кажется, пару раз кликали Excel, но это не точно.

Когда я спросил у учительницы (10-11), читает ли она какую-нибудь ИТ-литературу, то она сказала, что нет. Только то, что требуется для проведения занятия. Сейчас она уже несколько лет как переквалифицировалась в таргетолога и успешно настраивает рекламус московским толстосумам.
___
😎 Понравился пост? Подписывайся, чтобы не пропустить следующие!

Артем Лещев

🎉 Сегодня 13 сентября. 256-й день года. С днем программиста!

256, это 2⁸, то есть наибольшее количество различных значений, которые можно выразить одним байтом. Если кому интересно почему в байте 8 бит, то могу посоветовать вот эту статью. Спойлер: так исторически сложилось, 6-битный вариант тоже использовали. 8 достаточно для обработки букв обоих регистров и символов.

Также 256 — это максимальная целая степень числа 2, которая не превышает количество дней в году (365 или 366).

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

На QnA Habr мне когда-то попался безумно интересный комментарий (10-летней давности!) на что разрабы обращают внимание, во время код-ревью. 282 лайка! Это требования к PHP-коду, но там есть ряд вещей, которые будут: во-первых, актуальны для других языков; во-вторых, стоит иметь ввиду всем: менеджерам, аналитикам, тестировщикам.
Более формализовано, есть на Гитхабе у автора:
https://github.com/index0h/php-conventions

🙃 9 сентября, кстати, праздновался день лучшего друга программиста тестировщика. 9 сентября 1947 года в Гарвардском университете тестировали вычислительную машину Mark II Aiken Relay Calculator и нашли мотылька (по англ. moth), застрявшего между контактами реле. Грейс Хоппер (разработчица первого компилятора) тогда произнесла «bug», более общее слово для большинства мелких насекомых.
___
😎 Понравился пост? Подписывайся, чтобы не пропустить следующие!

Артем Лещев

😁 Частый вопрос на SQL-собеседованиях.

Какое минимальное и максимальное количество записей могут вывести INNER JOIN, LEFT JOIN, FULL JOIN, и какой должен быть набор значений? Сталкивались с таким вопросом? 🙃

Предварительные условия:

1. Обычно просят считать, что таблица "t1" содержит 10 значений, а таблица "t2" — 100. Для облегчения тестирования, мы будем считать, что в "t1" — 2 значения, а в "t2" — три.

2. Я добавил в примеры null-значения, для доп. иллюстрации действия.

3. Будем исходить из наиболее типичного условия фильтрации: t1.id = t2.id.

4. Разбираться будем на примере PostgreSQL.

Погнали!

➕ INNER JOIN

Минимум — 0 записей.
Набор данных — когда совпадений не найдено. То есть значения в одной таблице полностью отличаются от значений в другой (если есть null, то помним, что они друг другу не равны).
t1 = 1, null
t2 = 2, null, null

Максимум — декартово произведение (в нашем случае 2 х 3 = 6).
Набор данных — в обоих таблицах одни и те же значения, например, везде единицы.
t1 = 1, 1
t2 = 1, 1, 1

➕ LEFT JOIN

Минимум — количество записей в таблице, указанной во FROM. Соответственно, сюда надо поместить таблицу с меньшим кол-вом записей.
Набор данных — когда в обоих таблицах только разные значения. Нет совпадений. Соответственно, первая таблица (во FROM) отобразит все свои записи, и им приджойнятся null.
t1 = 1, null
t2 = 2, 3, null

Максимум — аналогично INNER JOIN. Декартово произведение (в нашем случае 2 х 3 = 6).
Набор данных — в обоих таблицах одни и те же значения, например, везде единицы.
t1 = 1, 1
t2 = 1, 1, 1

➕ RIGHT JOIN

Разница этих джойнов в том, что при LEFT будут отображены все записи таблицы из FROM, а при RIGHT — все записи таблицы из JOIN.

Минимум — количество записей в таблице, указанной после ключевых слов RIGHT JOIN. Соответственно, сюда надо поместить таблицу с меньшим кол-вом записей.
Набор данных — когда в обоих таблицах только разные значения. Нет совпадений. Соответственно, вторая таблица (не во FROM, а та, что после RIGHT JOIN) отобразит все свои записи, и им приджойнятся null.
t1 = 1, null
t2 = 2, 3, null

Максимум — аналогично LEFT JOIN. Декартово произведение (в нашем случае 2 х 3 = 6).
Набор данных — в обоих таблицах одни и те же значения, например, везде единицы.
t1 = 1, 1
t2 = 1, 1, 1

➕ FULL JOIN

Минимум — количество записей в бóльшей таблице (в нашем случае 3), при этом без разницы где она будет указана: во FROM или после JOIN.
Набор данных — каждое значение первой таблицы уникально и имеет только один аналог во второй таблице.
Соответственно, все значения первой таблицы найдут свою пару во второй. А лишние значение второй таблицы получат null.
t1 = 1, 2
t2 = 1, 2, 3

Максимум — декартово произведение (в нашем случае 2 х 3 = 6).
Набор данных — в обоих таблицах одни и те же значения, например, везде единицы.
t1 = 1, 1
t2 = 1, 1, 1

А что если все значения будут разными? Например:
t1 = null, null
t2 = null, null, null

отобразит 5 записей, т.к. FULL, LEFT, RIGHT джойны начинают выполняться с INNER-механики! А INNER JOIN для null-значений вернет 0 совпадений! Далее выполняется LEFT и RIGHT, итого 2 + 3 = 5 записей.

✏️ ИТОГО

Минимум:
INNER — 0;
LEFT — кол-во записей таблицы, указанной во FROM;
RIGHT — кол-во записей таблицы, указанной в RIGHT JOIN;
FULL — кол-во записей большей таблицы.
Максимум: INNER, LEFT, FULL создадут декартово произведение.

Если t1 имеет 10 записей, а t2 1000, то:
Минимум:
INNER — 0;
LEFT — 10 (указываем t1 во FROM);
RIGHT — 10 (указываем t1 после JOIN);
FULL — 100.
Максимум: 1000 записей.

🐧 Примеры кода можно посмотреть здесь:
https://dbfiddle.uk/jJjivYdm
___
Понравился пост? Подписывайся, чтобы не пропустить следующие.

Артем Лещев