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

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

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

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

Классификация фреймворков

Бэкенд-фреймворки

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

Например, при помощи Django вы можете сделать админку с гридами, о которой я писал выше. Это фреймворк на питоне.

Ещё можно выделить:

• Symfony, Laravel — PHP;
• Express.js — JavaScript;
• Ruby on Rails — Ruby.

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

Фронтенд-фреймворки

При помощи фронтенд-фреймворков вы напротив, можете реализовывать веб страницы с богатым содержанием, различными элементами интерфейса, кастомными и стандартизированными контролами. Различные анимации тоже можно делать с их помощью. Как правило, речь идёт о JS-фреймворках, например:

• Angular;
• Vue.js;
• Svelte;
• React — формально это не фреймворк, а библиотека, но значение этого инструмента так велико, что его постоянно сравнивают с другими веб-фреймворками.

Фуллстек-фреймворки

Сюда относятся фреймворки, реализующие как клиентскую, так и серверную часть. Например, JS Meteor.

Возможности фреймворков

Важное для менеджера

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

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

В целом, это всё, что пиэму нужно знать о фреймворках.

1

1

1

Error happened.

В изрядной доле проектов нужно интегрировать два или больше приложений. В самом тривиальном случае — фронтенд с бэкендом. В более сложном — мобильное приложение с бэкендом. В случае со звёздочкой — два бэкенда и другие извращения. Стандартом де-факто для таких задач в наше время считается API.

Кроме того, в вашем продукте может потребоваться реализовать дорогостоящую функцию, которая уже сделана в стороннем сервисе на отличненько. Например, если вам нужны карты, целесообразно использовать API Open Street Map или Яндекс.Карт, это сильно дешевле, чем пилить собственные карты.

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

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

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

Различия REST и SOAP

Чаще всего в современной разработке встречаются REST и SOAP API. Давайте разберём, в чём разница.

Типы запросов

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

1. GET
2. POST
3. PUT
4. PATCH
5. DELETE

GET – используется для получения со стороны севера определенного ресурса. Если вы производите этот запрос, сервер ищет информацию и отправляет ее вам назад. По сути, он производит операцию чтения на сервере. Дефолтный тип запросов.

POST – нужен для создания определенного ресурса на сервере. Сервер создает в базе данных новую сущность и оповещает вас, был ли процесс создания успешным. По сути, это операция создания.

PUT и PATCH – используются для обновления определенной информации на сервере. В таком случае сервер просто изменяет информацию существующих сущностей в базе данных и оповещает об успехе выполнения операции.

DELETE – как и следует из названия, удаляет указанную сущность из базы или сигнализирует об ошибке, если такой сущности в базе не было.

Postman

Для тестирования API применяется инструмент Postman. Раньше он был плагином для Хрома, но сейчас это автономное приложение для любых платформ. Штуковина достаточно понятная интуитивно, разработчики чаще всего передают данные об API тестировщикам именно в виде коллекций Постман.

Есть публичное API для смешных переводов, например, эндопоинт для перевода на язык Мастера Йоды находится по адресу: https://api.funtranslations.com/translate/yoda.json

Эндпоинт принимает только один строковый параметр text. Отправим Постманом GET запрос на этот эндпоинт:

Как видите, API возвращает такой ответ:

{
    "success": {
        "total": 1
    },
    "contents": {
        "translated": "Force be with you yoda,Polovec helloy you",
        "text": "Hello Yoda, Polovec helloy you",
        "translation": "yoda"
    }
}

Как нетрудно понять, эндоинт возвратил код успеха, а в поле контента передал три значения:

• translated — переведённый текст.
• text — исходный текст.
• translation — тип переводчика.

По такому же принципу работают любые REST API, только в реальных запросах параметров больше и они сложнее.

Применение в реальной разработке

Проектирует API обычно архитектор. Бэкенд-разработчики реализуют эндпоинты и пишут документацию. Фронтендеры или мобильные разработчики интегрируются с этим API, реализуют получение данных из него и отправку данных в него. Тестеры всё это проверяют.

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

Разное

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

Если вы интегрируетесь со сторонней системой и успех проекта сильно зависит от её корректной работы, попросите QA реализовать пинговалку стороннего API, они умеют это делать, в том числе с помощью Постмана. Система будет с определённой периодичностью слать запросы на внешнее API и если ответы перестанут поступать, будет записывать такие события в лог, с помощью которого вы потом сможете доказать, что разработка тормозила из-за отваливающегося стороннего API.

В целом, это всё, что пиэму нужно знать об API.

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

Для того, чтобы понять, зачем нужен Кубер, сначала нужно понять, зачем нужен Докер.

Docker

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

У вас может возникнуть вопрос, в чём разница докера и самой обычной виртуальной машины?

Контейнеры и виртуальные машины — это разные способы виртуализации. Только виртуалка реализует её на уровне железа, а Docker — на уровне операционной системы.

Виртуальная машина функционирует как отдельный компьютер с собственным оборудованием и операционной системой. Распространённая практика — купить большой сервер и установить на него гипервизор, базу для виртуалок. Сервер «нарезается» на много виртуальных компьютеров, что избавляет нас от необходимости покупать их отдельно.

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

Если цель виртуалки — полностью воспроизвести устройство компьютера, то основная цель Docker — создать среду для одного приложения. Виртуальная среда контейнера запускается внутри операционной системы. Ей не нужно виртуализировать оборудование — она использует его через ОС. Поэтому контейнеры Docker потребляют меньше ресурсов, быстрее развёртываются, проще масштабируются и меньше весят.

Если кратко перечислить преимущества контейнеризации, то это:

• быстрое создание и развертывание приложений;
• непрерывные разработка, интеграция и развертывание;
• разграничение ответственности разработчиков и администраторов; ‰‰
• однородность сред разработки, тестирования и промышленного использования; ‰‰
• переносимость между разными облачными провайдерами и ОС;
• сосредоточение управления непосредственно на приложении;
• слабо связанные, распределенные, эластичные, независимые микросервисы; ‰‰
• изоляция ресурсов;
• утилизация ресурсов.

Все основные облачные провайдеры, такие как Amazon AWS, Google’s GCE, Microsoft’s Azure и даже Alibaba Cloud, предоставляют услуги по размещению контейнеров.

Докер работает на линухе. Чтобы использовать его на винде или макоси, нужно ставить виртуальную машину с линуксом. Теперь несколько слов о том, из каких компонентов состоит Докер:

• Docker host — это операционная система, на которую устанавливают Docker и на которой он работает.
• Docker daemon — служба, которая управляет Docker-объектами: сетями, хранилищами, образами и контейнерами.
• Docker client — консольный клиент, при помощи которого пользователи взаимодействуют с Docker daemon и отправляют ему команды, создают контейнеры и управляют ими.
• Docker image — это неизменяемый образ, из которого разворачивается контейнер.
• Docker container — развёрнутое и запущенное приложение.
• Docker Registry — репозиторий, в котором хранятся образы.
• Dockerfile — файл-инструкция для сборки образа.
• Docker Compose — инструмент для управления несколькими контейнерами. Он позволяет создавать контейнеры и задавать их конфигурацию.
• Docker Desktop — GUI-клиент, который распространяется по GPL. Бесплатная версия работает на Windows, macOS, а с недавних пор и на Linux. Это очень удобный клиент, который отображает все сущности Docker и позволяет запустить однонодовый Kubernetes для компьютера.

Основных сущностей для работы с докером три:

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

Ещё есть специальный репозиторий для хранения докер-образов.

Вы вполне можете использовать Докер без Кубера, но Кубер даст дополнительные возможности.

Kubernetes

Если кратко, то Kubernetes – это ПО, позволяющее гибко управлять контейнеризированными приложениями. Штука целиком гугловая, опережает все аналоги очень сильно. В общем, если вам надо строить инфраструктуру под сколько-нибудь сложное и высоконагруженное приложение, Кубер ваш выбор. А если вы используете микросервисную архитектуру, сама наука велела изучить и использовать этот софт.

Сущностей в этой предметной области много, рассмотрим основные, чтобы более-менее понять размещённую выше схему.

Кластер

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

Узел

Узел — это отдельный компьютер (физический или виртуальный). Его задача состоит в запуске подов. Каждый узел в Kubernetes содержит несколько компонентов, таких как kubelet и прокси kube. Все они находятся под управлением ведущего узла. Узлы — это нечто наподобие рабочих пчел, которые занимаются выполнением всех основных задач. Устаревшее название узла — миньон.

Под

Под (pod) — это единица работы в Kubernetes. Каждый под содержит один или несколько контейнеров. Поды всегда работают совместно, то есть на одном компьютере. Все контейнеры внутри пода имеют одни и те же IP-адрес и пространство портов, они могут общаться между собой через локальный сервер или посредством межпроцессного взаимодействия. Кроме того, все контейнеры имеют доступ к общему локальному хранилищу данных узла, на котором находится под. Такое хранилище может быть подключено к каждому контейнеру.

Что же можно сделать при помощи Кубера?

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

Несколько слов о возможностях Кубера:

Мониторинг. Кубер позволяет в реальном времени мониторить множество параметров вашего кластера или отдельного приложения. Есть веб-интерфейс, инфа представляется в наглядном и удобном виде.

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

Оркестрация хранилища. С помощью Kubernetes разработчик может выбрать систему хранения: локальное хранилище, облако и т.д. Платформа автоматически создаст ее и настроит под потребности проекта.

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

Самоконтроль. Кубер умеет автоматически останавливать или перезапускать засбоивший контейнер. Девопс может задать критерии для качества работы контейнеров и Кубер будет скрывать от пользователей контейнеры, которые перестали им соответствовать. Ну и уведомлять девопса о таких событиях.

Безопасность и конфиденциальность. Kubernetes может сохранять и контролировать конфиденциальные данные (пароли, ключи SSH, OAuth-токены), распределять права доступа к системе. Обновление и развертывание приложений не затрагивает образы контейнеров и не раскрывает секретные сведения в конфигурации стека.

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

В целом, это всё, что пиэму нужно знать про Докер и Кубер.

2

1

1

1

Error happened.

Нужно ли пиэму программирование — вечная тема для холивара. Выскажу свой взгляд на этот вопрос и расскажу про другие хард скиллы, которые могут понадобиться руководителю проектов в различных организациях (а могут и не понадобиться). Речь пойдёт, конечно, об IT-пиэме.

Сначала нужно выучить терминологию, например, по этой статье.

Софт для календарно-сетевого планирования

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

Лучшее решение, которое я видел — плагин BigPicture для Jira. Позволяет брать реальные эпики и таски из джиры и из них делать «колбаски» ганта. Состояние задач в диаграмме будет апдейтиться автоматически. Даём гостевой доступ заказчику и ссылку на эту диаграмму и наступает общее счастье.

Если этот вариант невозможен, придётся использовать Microsoft Project для винды или аналоги для макоси, вроде Merlin Project или Omni Project. Все они устроены примерно одинаково.

Принципы ООП и основы программирования

Для того, чтобы понимать в речи разработчиков что-то, кроме предлогов, основы программирования знать и понимать нужно. Разберитесь, что такое переменная, цикл, ветвление, массив, класс, подкласс, экземпляр класса, объект, метод, интерфейс. Многое сразу станет понятно.

Также нужно разобраться, что такое гит, коммит, пулл-реквест, мердж-реквест, зачем нужен мердж веток, что такое мастер ветка.

Записываться на курсы разработчиков не нужно, это скорее навредит, чем поможет.

Умение собирать требования и писать ТЗ

Скорее всего, вам придётся начинать карьеру в маленькой компании, в которой на всех экономят, в том числе, на аналитиках, поэтому выяснять, что же нужно сделать в рамках проекта и оформлять всё это в читабельное ТЗ нужно вам. Пробегите Вигерса, хотя бы по диагонали, станет легче.

Да, в скраме нет ТЗ, там есть стори. Но легче от этого не становится, фичи всё равно, нужно расписывать, если этого не делать, разработчики закодят трешню. А если закодят не трешню, на этапе приёмки заказчик вам скажет, что имел в виду не это и вы ничего не сможете доказать, придётся переделывать.

Базы данных вообще и SQL в частности

Суть большинства проектов сводится к тому, что нужно сходить в БД за данными, красиво их отобразить, дать пользователю отредактировать, потом провалидировать и аккуратно сложить обратно. То есть, всё завязано на БД.

Вам нужно понимать, что такое БД, как она устроена. Что такое первичный ключ, внешний ключ, зачем нужны индексы и индексация. Может так сложиться, что вам придётся спроектировать модель данных. То есть, берёте предметную область проекта, выделяете сущности, декомпозируете их на атрибуты, делаете связи, скармливаете программисту, чтобы он из этого сделал БД.

Иногда бывает полезно уметь составить простенький запрос к какой-нибудь таблице с каким-нибудь условием.

Вот, например, код, выгребающий из одной базы подробную статистику трудозатрат по идентификатору доработки:

declare @id nvarchar(1000)
SET @id = 'CAS-191131-B8B3'


SELECT ROUND((SUM([Затраты])* 24), 2) as 'Итоговые затраты'
FROM [STAdministrationResource].[dbo].[vw_DO_TFS]

WHERE Затраты IS NOT NULL 
AND [Запрос.Номер CRM] LIKE @id


SELECT Роль, ФИО, Тикет, ROUND((SUM([Затраты])* 24), 2) as 'Затраты'
FROM [STAdministrationResource].[dbo].[vw_DO_TFS]

WHERE Затраты IS NOT NULL 
AND [Запрос.Номер CRM] LIKE @id

GROUP BY Роль, ФИО, Тикет
ORDER BY Роль, ФИО, Тикет

GO

Более сложные запросы нужны реже, можно попросить программиста помочь.

REST и SOAP API

Интеграция нужна практически везде, разве если только вы не делаете какой-нибудь калькулятор, да и то, хороший калькулятор должен уметь забирать курсы валют. Вам нужно разобраться, что такое API, зачем оно нужно. Советую сначала изучить SOAP, он интуитивно более понятен (на практике используется в энтерпрайзе для подруживания нескольких систем), потом изучите принципы REST (он используется на современных сайтах и веб-приложениях).

Научитесь читать и редактировать XML и JSON файлы. Если сильно не повезёт, вам могут поручить и проектирование API, у меня такое было раза три за карьеру.

Много очков в глазах работодателя даёт умение пользоваться Postman. Изучите его, он интуитивно понятный.

HTML и CSS

Разберитесь, как устроена HTML-страница, какие теги за что отвечают. Разберитесь, зачем вообще, нужен CSS. Принципы каскадирования и наследования в рамках соответствующих таблиц.

Потом научитесь пользоваться консолью разработчика, хотя бы в одном браузере. Очень важно уметь посмотреть, какие стили применились к данному элементу страницы и если надо, их подправить. Также нужно уметь пользоваться консолью ошибок, потому что первый вопрос, который вам задаст разработчик в ответ на ваше: «На сайте ошибка», будет: «Что в консоли?».

Во всяких бутстрапах разбираться необязательно.

Устройство админки популярных CMS.

Скорее всего, в работе вы столкнётесь либо с Битрикс, либо с WordPress. Очень полезный навык — умение разобраться, где в админке поправить данный кусок контента и сделать это, когда это нужно срочно, а контентер уже спит.

Таблицы

Изрядная часть работы пиэма связана с созданием и редактированием разнообразнейших таблиц. Чем лучше вы владеете Excel и гуглотаблицами, тем выше ваша продуктивность и ценность. В Скайэнге вообще, требуют в тестовом на пиэма задание, предполагающее написание макросов, но это единичный случай.

Сюда же входят навыки по работе с матрицей рисков, которую часто исполняют в виде обычной таблицы.

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

Вот хороший телеграм-канал про секреты гуглотаблиц.

Основы девопс

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