🔄 ♻️ Работаем с командами 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
___
Понравился пост? Подписывайся, чтобы не пропустить следующие.

Артем Лещев

😁 Регулярные выражения.

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

В данном посте освещу любопытный синтаксис ретроспективных (Lookbehind) и опережающих (Lookahead) проверок. Каждая из них бывает двух видов, итого имеем четыре вариации:

Positive Lookbehind — (?<=Y)X — найти Х, при условии, что до него идет Y.
Negative Lookbehind — (?<!Y)X — найти Х, при условии, что до него НЕ идет Y.
Positive Lookahead — X(?=Y) — найти Х, при условии, что после него идет Y.
Negative Lookahead — Х(?!Y) — найти Х, при условии, что после него НЕ идет Y.

➕ Positive Lookbehind и Positive Lookahead. Найдем случаи, когда буквы и цифры слиплись в одно слово.

(?<=\d+)[а-я].*?(?=\s)

Шаурма стоит 199рублей и 99 копеек

Регулярка найдет "рублей"

➡️ (?<=\d+) Positive Lookbehind. Проверяет, что как минимум одна цифра есть до букв.
➡️ [а-я] проверяет наличие одной русской буквы от а до я (после цифр у нас как раз идет буква "р").

Таким образом мы уже нашли совпадение. Но, допустим, мы хотим поймать проблемное слово целиком, а не только одну букву. Пишем дальше:

➡️ . точка означает, что после буквы может идти любой символ. В нашем случае, это буква "у".
➡️ * звездочка уточняет, что данных символов может быть >=ноль (то есть пока строка не закончится).
➡️ ? вопрос по-умолчанию означает «ноль или один», что делает любой символ необязательным.
➡️ (?=\s) Positive Lookahead. Пробел.

В совокупности:

➡️ .* захватывает как можно больше символов, пока не уткнется в пробел. Это так называемый жадный (greed) эффект. Поскольку пробел сам по себе это тоже символ, подпадающий под точку, то (?=\s) подразумевает последний пробел в строке.

Нам последний пробел не нужен, ведь тогда регулярка выделит "рублей и 99".
Чтобы (?=\s) подразумевал пробел после слова "рублей", надо сделать так, чтобы .* захватил как можно меньше символов до пробела. Для этого ставим после него знак вопроса.

➡️ .*? захватывает как можно меньше символов, пока не уткнется в пробел. Получается так называемый ленивый (lazy) эффект.

➕ Negative Lookbehind и Negative Lookahead. Опять найдем случаи, когда буквы и цифры слиплись в одно слово.

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

(?<!\d+\s)(рублей|копеек)|\d+(?!\s(копеек|рублей))

Бургер стоит: 99рублей и 99копеек

Регулярка найдет "99рублей" и "99копеек".

➡️ (?<!\d+\s) Negative Lookbehind. Проверяет, что как минимум одна цифра и пробел отсутствуют до слов.
(рублей|копеек) в скобках указывается вложенность меньшей логики внутри более обширной логики. В данном идет проверка логического ИЛИ.
➡️ | Прямой слэш как раз и означает логическое ИЛИ. По-скольку слэш указан не в скобках, а в самой регулярке, то он разделяет саму регулярку на 2 части. На Negative Lookbehind и Negative Lookahead.
➡️ \d+(?!\s(копеек|рублей)) это и есть Negative Lookahead. Проверяет, что как минимум одна цифра не имеет пробела отделяющего либо "копеек", либо "рублей".

🐧 Понравился пост? Подписывайся, чтобы не пропустить следующие.
А вам доводилось писать регулярки на работе?

Артем Лещев

😁 Чуть поюзаем сниффер. Смотрим незашифрованные данные, отправляемые по HTTP.

То, что голый HTTP небезопасен, слышали многие. Как это протестить?

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

✔️ Скачаем и установим Wireshark — наверное, самый известный бесплатный анализатор.

1️⃣ Запускаем. В стартовом окне приложения видим список интерфейсов для захвата трафика.

2️⃣ По-скольку я сижу в Интернете подключившись к своему Wi-fi, то я выбираю "Беспроводная сеть". Хоба, всевозможные запросы летят. Ставим фильтр на http.

3️⃣ Теперь нужно открыть сайт в котором нет редиректа http -> https, либо у которого просто http (т.е. вообще нет TLS-сертификата).

Для теста, можно взять сайт OLD DOS — крупнейший в Рунете архив старых программ.
http://old-dos.ru/

Вероятно, отсутствие https у него чисто символическое 😁, т.к. сайт посвящен старому софту былых времен.

4️⃣ Регистрируемся на сайте, и, после успешной попыки, видим в Wireshark POST-запрос. Кликаем на него, раскрываем HTML Form URL Encoded и видим наши e-mail, пароль, а также данные капчи.

Все это отсутствовало бы, при наличии https.

🐧 Понравился пост? Подписывайся, чтобы не пропустить следующие.

Артем Лещев

Последнее время мне приходится сталкиваться с различными ИБ-ситуациями.

➡️ То обсуждал интеграцию без использования JWT-токена, но с mTLS-сертификатом. Отказались, решили, что служба ИБ не пропустит.

➡️ То недавно сделал пост о том, как смотреть через сниффер информацию, передаваемую по голому HTTP. А также поюзал Postman Interceptor, как рекомендовал Антон Зимин (владелец Чулана СА). Правда, на HH установлен 301-редирект, так что не получилось там ничего интересного посмотреть.

➡️ То мошенники добавили маму в чат в Телеграме где писали, якобы "проходит оцифровка архива" и прислали ссылку на "официальный бот ГосУслуг" с чудесным, совершенно не палевным названием "Моu документы".
Кому интересна схема, почитайте здесь: https://www.audit-it.ru/news/finance/1124474.html

Заметил, что и сами мошенники накосячили.

1️⃣ Жертву добавляют в коллективный чат (из 5-6 аккаунтов-мошенников) и просят через бота сгенерировать код и прислать в чат.
2️⃣ Когда жертва скидывает в чат код, то скрипты моментально отгружают в чат насмехательские сообщения от каждого аккаунта.
3️⃣ Рассказал маме, что раз уж эти сообщения появились:
а) все разом;
б) моментально, после того как она отправила код в чат,

то это всё заранее запрограммированные действия. Никакого доступа к Госуслугам они не получили. Их цель — вызвать панику.

Имхо, если бы в скрипты был добавлен sleep()-метод, то отгружающие сообщения появились не сразу, и это было бы гораздо правдоподобнее:

import time

message = 'Я тебя взломал!!!'
time.sleep(10)
print(message) # Появится через 10 секунд, после запуска кода.

➡️ То присутствовал на дне рождения, где среди гостей была начальница ИБ одной организации. Уточнил занимаются ли они пентестом. Потом объяснял одной любознательной гостье что такое пентест. А потом ей же объяснял что такое реверс-инжиниринг (а рядом сидел мой знакомый плюсовик и внимательно меня слушал). Коллективно вспомнили новость с Аэрофлотом.

➡️ Ну а видос со Смешариками — это из 3-й серии "На крючке" цикла "Азбука цифровой грамотности".

🐧 Понравился пост? Подписывайся, чтобы не пропустить следующие!

Артем Лещев

😁 Брось в меня камень, если никогда так не писал.

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

Узнал что слова "функционал" и "функциональность" имеют разные смыслы. В контексте ИТ-требований, якобы, правильно говорить "функциональность". Исходная статья:
https://vc.ru/flood/283778-funkcionalnost-ili-funkcional-obyasnyaem-kak-pisat

Не могу согласиться с этой статьей. Слова меняются с течением времени: могут укорачиваться, сливаться с другими, старые значения исчезают, появляются новые смыслы... Это нормальный процесс развития языка.

Прикрепляю комментарий от лингвиста:
https://aif.ru/society/education/funkcional_ili_funkcionalnost_kak_pravilno

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

Думается, что мнение филолога весомее (аналогично тому, что зубы я буду лечить у стоматолога, а не у слесаря).

В общем, я легко могу простить аналитику использование слова "функционал".

‼️ А вот, что действительно неправильно, так это склонять английские слова с помощью апострофа: применение React'а, запрос на SQL'е.

Выглядит как икота! 😁

Вспоминая библейский сюжет, "брось в меня камень, если никогда так не писал". Увы, но я тоже замечен за использованием апострофа. Отучаюсь.

Иногда люди могут аналогично использовать дефис, что тоже неправильно. Через дефис пишутся сложносоставные слова с несклоняемой первой частью: Wi-Fi-роутер, web-браузер, веб-браузер.

Если дюже хочется просклонять слово, то его стоит написать по-русски: применение Реакта, кодить на Пайтоне.

Переводить нежелательно: более корректно будет "Пайтон", а не "Питон". Аналогично тому, что мы не переводим иностранные города: Сан-Франциско (а не "святой Франциск"), Солт-Лейк-Сити (а не "город у Солёного озера").
Хотя, иногда с топонимами все-же есть исключения: Красная площадь, это Red Square, а не Krasnaya Square.

Со склонением аббревиатур такое не прокатит, ибо это тоже неправильно. "Запрос на ЭсКьюЭле" выглядит жутко, я бы сказал.

Лучше использовать такой формат:
(0) вначале русское слово;
(1) английская аббревиатура;
(2) дефис;
(3) и русское слово в нужном склонении.
Пример: "Ошибка в SQL-запросе", "Уволили PHP-разработчика".

🐧 Понравился пост? Подписывайся, чтобы не пропустить следующий.

Артем Лещев

😁 Посетил конференцию Ольги Пономаревой (как зритель).

Слушал 2 доклада:
(1) Владимир Бурмистров — Документируй это. Как артефакты аналитика становятся топливом для проекта, а не бюрократией".
(2) Денис Рязанов — Проходим IT интервью. Как не «посыпаться» на вопросах по базам данных.

В этом посте зафиксирую что рассказал Владимир. Мы с ним оба трудоустроены в Иннотех, только я на проекте ВТБ, а он в DION (прога для проведения видеоконференций).

Сразу с козырей: этот мем Вова упоминал на выступлении. Сделал для вас в более лучшем качестве, чем нашел в инете. Юзал ИИ и Его Величество Paint. Хотя, тэгэшка все равно чутка пожала качество.

Итак, документация бывает разная:
​​​​​​​
1️⃣ Верхнеуровневый концепт (Solution Concept).

Целевая аудитория:
Для разного начальства: PO, архитекторы, техлиды команд.

Что внутри?
Цели и задачи; краткое описание; список требований (без Use cases); допущения и ограничения; C1/C2 из C4-нотации; Architecture Decision Records (описание что решили делать и почему именно так, какие были альтернативы, чем что чревато).

2️⃣ Бизнес-требования (BRS).

Целевая аудитория:
Для PO, команды разработки в целом, дизайнеры.

Что внутри?
Глоссарий, User stories, AS IS-TO BE, критерии приемки в формате Given-When-Then, НФТ, анализ конкурентов.

3️⃣ ТЗ (SRS).

Целевая аудитория:
Для разработчиков. И, я бы еще сказал, для тестировщиков (для раздербанивания на тест-кейсы).

Что внутри?
Начнаем с краткого описания функциональности. Таблица именений Backend/Frontend, изменения таблиц БД, sequence-диаграмма, описание API, маппинг UI и API, НФТ.

Отдельно был дан совет пользоваться ИИ.

Поможет в генерации (User stories, PlantUML-код, глоссарии, контракты API на основе API конкурентов), улучшить критерии приемки, анализ конкурентов, уточнить прошлые генерации.

Была порекомендована книга Карла Вигерса «Жемчужины разработки. Чему мы научились за 50 лет создания ПО».

Про доклад Дениса Рязанова расскажу отдельным постом.

🐧 Понравился пост? Подписывайся, чтобы не пропустить следующий.

Артем Лещев

Сегодня отмечается День системного аналитика!

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

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

Если кратко:

В кругах системных аналитиках существует миф о том, что День СА празднуется, якобы, 24 сентября.

На различных ресурсах:

(1) либо указывается Тед Кекатос, как основатель праздника. Якобы, он 24 (или иногда 20 пишут) сентября 2000 года организовал в США пикник; либо

(2) упоминаеся, что 24 сентября 2000 года был опубликован российский документ по методологии проектирования информационных систем.

Собственно, первый пункт, касается сисадминов, а по второму вообще нет никакой доказательной базы.

Зато есть сайт https://www.systemsengineerday.com/, который, увы, обновлялся последний раз год назад.

На нем указано, что системных инженеров могут называть по-разному. Среди вариаций названий фигурирует Systems Analysts. И действительно: изучение статьи Systems_engineering в английской Википедии, явно приводит к мысли, что системный инженер занимается как раз тем же самым, что и СА: уточняет требования, пишет ТЗ, моделирует, проектирует, пишет документацию, согласовывает...

Ну а сам сайт, вероятно, принадлежит основателю праздника Николасу Фури. Этот сайт указан на странице Николаса в LinkedIn.

С праздником!

🐧 Понравился пост? Подписывайся, чтобы не пропустить следующий.

Артем Лещев

😁 Я календарь переверну...

И снова 29 ноября. Я 4 года работаю в ИТ! От программиста в муниципальном предприятии до ведущего системного аналитика на проекте ВТБ.

Итак, пошел 5-й год. Что я понял за это время?

➕ Самое сложное в IT — вовсе не изучать новые технологии. Это изучать предметную область бизнеса. И делать это приходится всем: менеджерам, аналитикам, разработчикам, тестировщикам, сопровожденцам...

✔️ Самый недооцененный хард-скилл — уметь программировать. Можно свитчнуться в другие сферы, если выгоришь в одной; проще двигаться по карьерной лестнице, например, получить должность архитектора; можно самому посмотреть логику слабодокументированных функциональностей; да хоть создать собственный продукт...

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

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

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

✔️ Искусственное никогда не будет цениться дороже, чем настоящее. Если человек не умеет работать самостоятельно, то ИИ ему не помощник. Мне даже неинтересно что там ИИ придумал, если я знаю что автор промпта сам по себе низкоквалифицирован.

А на фото, я провожу свой отпуск в Питере! Зимний дворец и корабль Полтава, на который, к сожалению, сейчас экскурсии не проводятся. Все это было на прошлой неделе. Чего только не посетил! Кунсткамера, Аврора, Петропавловская крепость, Исаакиевский и Казанский соборы и так далее.

☄️ Даже был на митапе Positive Technologies по инфобезу как ИИ ловит хакеров (но на выложенных фото меня нет 😔).
⚡️ И еще был в музее компьютерной техники Яндекса на Невском проспекте, 68А.

🐧 Понравился пост? Подписывайся, чтобы не пропустить следующий.

Артем Лещев