Карьера аналитика

🤔Что такое JSON и в чем его отличие от JSON Schema JSON - это один из самых популярных (а скорее всего и самый) форматов обмена данными на данный момент и он используется повсеместно. Также его можно встретить в требованиях к кандидату для любой вакансии системного аналитика. ❔Что же это такое? JSON (JavaScript Object Notation) — это структурированный текстовый формат обмена данными. Легко читается людьми. Имеет открытый стандарт. Где используется JSON независим от языков программирования и часто используется для, например: 💩при обмене данными через API. Например, в качестве одного из вариантов передачи body HTTP-запроса - мы можем использовать формат JSON (но это может быть также XML); 💩при создании конфигурационных параметров систем и (микро)сервисов. Например, достаточно часто мы хотим не хардкодить какие-то переменные значения и не зашивать их в код, а сделать их динамическими, для того чтобы не требовалось при изменении этих атрибутов каждый раз привлекать разработчкиов. Для этого, "под ногами" у сервиса создается конфигурационный файл формата .yaml, в котором в формате json указываются необходимые нам настройки. И при необходимости их изменить, поддержка (обычно) изменяет конфигурационный файл, после чего перезапускает сервис, который, в свою очередь, подхватывает обновленный файл и использует уже новые настройки - удобно и быстро. 💩в NoSQL базах данных, например, в MongoDB. Т.е. мы можем хранить прям объект или массив объектов целиком в формате JSON в нереляционных базах. Синтаксис Json-объект — это неупорядоченное множество пар вида {"ключ": "значение"}. ➖Ключ – это название параметра, пишется в двойных кавычках; ➖Значение для ключа указывается после двоеточия; ➖Между парами ключ-значение ставится запятая. После последней пары запятая не ставится; ➖Писать ключи можно в любом порядке. Типы данных ➖Строка – "name": "Сергей" ➖Число – целое или с запятой – "years": 24 ➖Логический тип, boolean – true или false – "active": true ➖Массив – "names": [ "Сергей", "Алексей" ] ➖Объект – "person": { "name": "Сергей", "age": 29 } ➖null – пустое значение – "children": null Как нам указывать поля с типом “дата”? JSON не даёт строгих указаний, в каком формате передавать дату и время. Можно использовать unix-time или передавать дату в строке, например, "2008-01-21T11:25:43-05:00". JSON Schema JSON Schema – это способ описания структуры и ограничений JSON-документов. В большинстве случае применяется для валидации данных при обмене информации между разными системами (часто можно ее встретить в том же swagger). С помощью ключевых слов в схеме создаются правила валидации структуры объекта и типов его полей. Пример такой схемы:

{ "$schema": "http://json-schema.org/draft-04/schema#", "title": "Product", "description": "A product from Acme's catalog", "type": "object", "properties": { "id": { "description": "The unique identifier for a product", "type": "integer" }, "name": { "description": "Name of the product", "type": "string" }, "price": { "type": "number", "minimum": 0, } }, "required": ["id", "name", "price"] }

Эта схема нам говорит о том, что у объекта "Продукт" есть три атрибута: идентификатор, название и стоимость, каждый из которых обязателен и при этом стоимость не может быть отрицательной. Что позволяет нам валидировать этот объект если, например, ожидаем его получить на вход какого-нибудь нашего метода. Если этот объект не будет удовлетворять указанным требованиям, то мы смело вернем ошибку валидации на такой запрос.

По выходным делаю для вас контент в новом, для себя и канала, формате. После большого зимнего перерыва снова нашел в себе мотивацию и силы для творчества, чего мне не хватало последнее время. Поэтому снова горю, генерирую идеи, кайфую от процесса. А под такое настроение всегда находятся возможности, которые позволяют все эти идеи реализовать (и как всегда они сильно ближе, чем мы думаем, но об этом расскажу в другой раз), и которые мы обычно не замечаем из-за усталости\переживаний\проблем. Считайте это анонсом >3

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

❗️Завышение стажа в резюме: работает или нет? Я думаю многие из вас так или иначе сталкивались, либо слышали, про такой прием при поиске работы - как завышение своего стажа (либо накручивание его вообще, если его совсем нет). А одна из последних прочитанных мной новостей (реальных или нет - это уже другой вопрос), сподвигла меня написать свое мнение на этот счет. Вообще, за 2023 год история с накруткой опыта набрала прям очень большую популярность, потому что было много успешных кейсов, о которых многие спешили поделиться в соц сетях. Появились даже несколько каналов, в которые такие истории регулярно публикуются (рекламировать, конечно не буду). Некоторые из них правда заканчивались очень неудачно для решивших поделиться, потому что их работодали наткнулись на эти посты и неприятно удивились. Поэтому если уж вы воспользовались таким способом, то хотя бы не распространяйтесь об этом =) И подобные методики даже полу-официально предлагали некоторые известные и крупные курсы, которые обещали своим студентам гарантию трудоустройства, а тут, как известно, все способы хороши. Как это работает? На самом деле очень просто, т.к. основная проблема это не пройти техническое собеседование, а именно дойти до него. Прорваться сквозь труднопреодолимый барьер рекрутеров\HR, которые часто даже не смотрят резюме в котором нет хотя бы года релевантного опыта. Поэтому люди просто добавляют некий выдуманный опыт строчкой в резюме и это сразу же повышает конверсию просмотров, заинтересованность рекрутеров и соответственно количество "проходок" на собеседование. А всё потому, что у работодателя нет возможности убедиться в реальности того опыта, который указан в резюме. По крайней мере на уровне HR, а иногда и на уровне СБ, насколько я понимаю. А уж спустя несколько собесов, научиться отвечать социально одобряемым образом на вопросы интервьюера (благо они очень часто одинаковые) - достаточно не сложно. Особенно если ты за энное количество собесов научился держаться уверенно, прокачал скилл их прохождения ив целом производишь благоприятное впечатление. Даже если у тебя слабенькая база. Если ты еще и действительно учился, понимаешь тему, готовился и так далее - то это еще сильнее облегчает собес. Поэтому данный способ достаточно часто срабатывает в плюс и ты начинаешь получать офферы. Не буду давать моральную оценку данному способу, потому что все хотят найти достойную работу, а конкуренция далеко не маленькая. Если есть лазейка чтобы попасть на работу и начать зарабатывать деньги - ну что ж, дело сугубо материальное, осуждать это я не в праве. ❕Однако, лично мое мнение в том, что не нужно перебарщивать. Я имею ввиду то, что если у вас совсем нет опыта - не нужно сразу устраиваться на миддла или сеньора, накручивая слишком большой опыт (такое, судя по некоторым историям, тоже реально). Одно дело без опыта начать работать джуном - от тебя многого ждать не будут, вполне может прокатить и тебя не "раскроют". Но если ты пройдешь на того же миддла и даже не сможешь разговаривать с командой на одном языке - то в чем смысл? Не говоря уже о том, что ты не сможешь выполнять свои задачи самостоятельно, чего ждут от специалиста этого уровня. Испытательный вы вряд ли пройдете, да еще и информация о вас может распространиться в разнообразных чатиках. Поэтому единственный совет - подходите ко всему разумно. P.S. своим студентам я такое не рекомендую и даже не упоминаю такой вариант. Я предпочитаю вариант с повышением конверсии и внимания со стороны рекрутеров через улучшения качества резюме. Добавление ключевых слов, переиспользование текущего опыта, казалось бы не релевантного, в рамках новой профессии и так далее. Все это вполне возможно через консультацию с хорошим карьерным консультантом. И никакого обмана (хотя, конечно, возможно не так эффективно как докрутить себе год или два и придется искать работу месяц, а то и два=) ).

❕Немного о событиях последних двух месяцев (и не только) Как обычно, перед новым годом и своим днем рождениям у меня случилась пауза в ведении канала и любых других активностей, кроме работы. 1️⃣Во-первых потому что этой самой работы было достаточно много (как всегда под конец года); 2️⃣Во-вторых потому что перед свои днем рождения у меня силы обычно на полном нуле и особо нет возможности их распылять на что-то еще. Правда сейчас эта пауза уже достаточно затянулась, поэтому пытаюсь вернуться в своё продуктивное русло. Зато за это время было много интересных задач, много интеграционных историй, которые успешно получилось реализовать (или вступить на путь к их реализации, что тоже не мало =) ). Подумал, что надо больше рассказывать о каких-то практических примерах задач, в обезличенном виде, и примерных вариантах их решения, потому что это может быть полезно для понимания того, какую работу мы (аналитики), вообще выполняем и может иметь практическую пользу для кого-то из вас в том числе. Например, одна из интересных задач, которая была у меня на практике - это интеграция нашего кредитного конвейера с ДБО для того, чтобы клиент мог удаленно подписывать свой КОД (кредитно-обеспечительную документацию) удаленно, в своём мобильном приложении, без необходимости личного присутствия в офисе. Сейчас это не новость и в принципе это реализовано уже много где, да и в целом мы все с большой силой стремимся в цифровизацию, безбумажность и вот это всё новое, удобное и красивое. А всё для того, чтобы людям было удобно и просто пользоваться любыми ресурсами (круто же иметь Госуслуги, личные кабинеты во всех сервисах\банках, которые предоставляют огромное количество функций и возможностей решить почти любые вопросы удаленно? А это всё мы, команды разработки. Ну и наши любимые заказчики, которые все эти идеи круто накидывают на вентилятор). По-моему я только из-за этого до сих пор держусь и не выгораю. Кхм, да, отвлекся. С точки зрения бизнеса задача была предельно понятна. Взять те документы, которые сформировал наш Кредитный конвейер (КК) и отправить их в систему ДБО, чтобы они отобразились у клиента и он мог ознакомиться с ними, нажать на кнопочку и подписать. Ну и потом эти документы должны были отправиться к нам, чтобы мы узнали о том, были ли они подписаны или нет и далее пользоваться уже подписанной версией. С технической точки зрения всё было несколько сложнее. Начнем с того, что у нас разные файловые хранилища (что плохо, но уж как есть) и соответственно нам надо было брать документы из нашего ФХ, сохранять их в ФХ ДБО и только после этого отправлять определенный список документов в ДБО для подписания. Первая часть интеграции, по получению\сохранению документов, должна была идти синхронно, вторая уже асинхронно, потому чтоэто надежно, ну и с бизнесовой точки зрения у клиента было время на подумать, хочет он вообще это подписывать или не особо. Поэтому ответ нам приходил уже также асинхронно. И вот задача как раз заключалсь в том, чтобы придумать это решение (архитекторов не было, но в данном случае он и не особо нужен был, потому что решение лежало на поверхности), проработать все нюансы (как загружать в ФХ, как оно вообще работает, какой набор документов, как скачивать, какой атрибутивный состав сообщения для ДБО должен быть, что мы ждем в ответ и когда и т.д.) и описать это решение, что занимает не так мало времени. Но ковыряться со всем этим достаточно интересно. В следующей части поста набросаю примерную схемку этого решения и дам еще пару комментариев. P.S. Кстати, результаты опроса, который я закидывал позавчера достаточно ожидаемы почти во всем, но я таки удивлен, что аж 40% людей нравится рисовать диаграммы, а 42% нравится консультировать команду. Я думал тут будет значительно меньше голосов, но это интересно, в любом случае. Спасибо, что вы остается активными, даже спустя такой перерыв в постинге ❤️

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

📊Диаграммы, часть 7. Где рисовать? Сегодня не надолго вернемся к диаграммам - был ряд вопросов на тему того, какой инструмент лучше использовать для отрисовки той или иной диаграммы. Что касается UML - если не брать сложные архитектурные инструменты, типа Enterprise Architect, Archimate и вот это вот всё, то системному аналитику для использования будет достаточно одного из следующих: 1️⃣Visio - хорошо подходит для отрисовки диаграмм UML (и не только) любой сложности. Платный. 2️⃣ Lucidchart - аналогичный онлайн-инструмент, который поддерживает не только UML, но и всякие там диаграммы Ганта (если они вдруг кому-то еще интересны), mindmap'ы и так далее. Условно-бесплатный. 3️⃣ Creately - тоже не могу чем-то выделить, все эти инструменты достаточно похожи. И так далее. На самом деле достаточно вбить в поисковую строку запрос "UML online" и там будет достаточно много выбора из платных или бесплатных инструментов. Но этими я пользовался, они хорошо заходят и достаточно удобны в освоении. Но! Кроме этого, если возможность отрисовывать UML-диаграммы не только через графические редакторы, но и через письменные движки. Это такие инструменты, которые обрабатывают написанный вами текст и преобразуют его в ту или иную uml-диаграмму. Кто еще не пробовал - очень рекомендую. Лично я пользуюсь именно этим способом, потому что для меня он более ламповый и уютный. Хотя не могу не сказать, что с непривычки он будет более медленный, чем набрасываение различных компонентов UML с графической формы (но, что интересно, многие аналитики пользуются именно им - хотя я сам для себя не могу объяснить, почему я выбираю этот способ). Основной инструмент подобного типа - это, конечно же, PlantUML. Он поддерживает любые диаграммы UML и даже больше. Плюс у него есть очень понятное справочное руководство для каждой из типов диаграмм. Пример скину в следующем посте картинкой. Поэтому - если вдруг не пользовались и хотите что-то новое, то welcome. Что касается BPMN - тут все аналогично, вбиваете запрос "BPMN онлайн" и выбираете приглянувшийся инструмент. Из тех что я пользовался, это: 1️⃣bpmn.io 2️⃣Camunda Но в целом тут порекомендую скачать десктопную версию camunda modeler - что особенно актуально, если у вас на проекте применяется BPMN-движок бизнес-процессов, а не просто рисуете BPMN схемы для заказчика или команды. P.S. Недавно находил еще один аналог PlantUml из свежих, который меня зацепил не только функционалом, но и дизайном, но я забыль как он называется. Если найду - напишу. А какие инструменты вы используете?

🤔Подходы к детализации проработки ТЗ системным аналитиком Давненько я тут ничего не писал - навалились личные дела, много работы и учеников. Да и в целом, у меня периодически бывают периоды застоя, когда я в очередной раз не знаю о чем писать - возникает ощущение, что я уже обо всем столько всего написал, а о чем можно еще - идей нет. Но потом это проходит и эти идеи так или иначе генерятся. Но как раз по этой причине часто прошу вас выдвигать свои темы для обсуждения - поэтому всегда добро пожаловать в комментарии с какими-то идеями или запросами на освещения каких-либо тем. Это всегда приветствуется, т.к. снимает меня часть нагрузки по придумыванию следующих тем 😅 Т.к. пост получился очень большим и не влезает в стандартный формат телеги - то оформил его в телеграфе. После прочтения - оставьте свой комментарий о том, в рамках какого процесса из перечисленных четырех вам довелось работать и какой из них вам наиболее комортный? Несмотря на то, что я топлю за псевдокод, полноценное, супер детальное описание и вот это всё - вполне могу понять, когда комфортно работать по-другому. Поэтому с удовольствием обсужу плюсы и минусы любого подхода. А в следующих постах попытаюсь порассуждать на тему того, почему вообще получилась настолько большая разница в степени участия системных аналитиков в тех или иных проектов.

📊Диаграммы, часть 5. BPMN, легенда. По запросам трудящихся учащихся, сделаю отдельным постом легенду для тех элементов BPMN, про которые рассказывал в прошлом посте. Цифрами обозначены картинки в их порядке прикладывания. 1. Event - событие; 2. Activity - задача; 3. Gateway - шлюз; 4. Flow - поток; 5. Pool - пул; 6. Message - сообщение; 7. Artefact - артефакт. Также стоит можно использовать элементы, типа событий\развилок\сообщений, внутрь которых вложены другие элементы. Например таймер, сообщения и так далее. Т.е. таким образом можно обозначать, что событие будет начинаться\заканчиваться по таймер или по получению какого-то сообщения - см. картинку 8 и 9. P.S. Спасибо за интерес и за вопросы, которые вы задаете) Если есть какие-то темы, которые вы хотите, чтобы я разобрал - всегда рад таким запросам.

📊Диаграммы, часть 5. BPMN. Продолжаем серию постов про диаграммы. Сегодня наконец поговорим про BPMN. Business Process Model and Notation (нотация моделирования бизнес-процессов) — это система условных обозначений, которая отображает бизнес-процессы с помощью блок-схем. BPMN показывает в какой последовательности совершаются рабочие действия и перемещаются потоки информации. Наглядная схема показывает, где в процессах есть узкие места или вовсе тупики, из-за которых клиенты уходят или не заканчивают целевое действие (заявка, покупка, звонок). BPMN подсвечивает места, которые можно улучшить и моделирует способы адаптации под новые условия. BPMN-схемы описывают бизнес-процессы единым стандартизированным языком, который понятен всем участникам независимо от уровня их технических познаний. Я думаю, что прочитать схему, изображенную на первом скриншоте, сможет каждый из вас даже без предварительной подготовки. Теперь немного о базовых объектах BPMN: ● Event – Событие. События могут быть начальными, конечными или промежуточными. Например, опишем процесс получения заказа от клиента по телефону: - Событие Старт – это входящий звонок от клиента. - Событие Финиш – это отправка готового расходного документа на печать. ● Activity – Действия. Это те действия (задачи), которые должны быть выполнены на определенном этапе бизнес-процесса. Их при моделировании обычно обозначают в виде прямоугольников, в которые вписывают суть действия. ● Gateway – Шлюзы или Развилки. Это контрольный узел, который появляется в случае условного ветвления бизнес-процесса. Графически изображается в виде ромба. Также шлюзы необходимы в случаях, когда порядок действий зависит от тех или иных факторов. Например, при работе с заказчиками шлюз появляется на этапе принятия клиентом решения о покупке – «да или нет». При положительном решении необходимо оформить покупку, при отрицательном – выяснить возможные причины отказа, провести работу с «отказом» и т.д. ● Flow – Поток. Это последовательность действий, обозначается как стрелка, и показывает, какое действие после какого необходимо совершить. Есть несколько видов потоков, но все кроме обычной прямой стрелки используется достаточно редко (к сожалению или нет, вопрос остается открытым). ● Pool (Пул) — набор. Пул – это объект описывающий какой-то один процесс на диаграмме. Он может быть не изображен на диаграмме, но он всегда есть. На одной диаграмме может быть несколько Пулов. Пул можно развернуть для просмотра деталей. ● Swimline – «плавательные дорожки». Пул может также содержать, так называемые, «дорожки». Они нужны для того, чтобы указать участников процессов, которые скрыты в пуле. Например, в процессе работы с клиентами участвует менеджер по продажам, руководитель отдела продаж, возможно, бухгалтер или кассир. Это основные объекты BPMN, которые чаще всего используются. Кроме перечисленных есть еще не мало других, но они используются уже реже и о них можно почитать отдельно. И что еще важно - BPMN можно на самом деле использовать не только для построения бизнес-процессов, но и для описания тех же интеграций. Да, это не по фэншую, но кто нам может запретить? См. второй приложенный скриншот для примера.

Запись эфира про карьеру в ИТ У нас был неформальный разговор и много примеров из практики. Отдельное спасибо всем, кто пришел и за ваши вопросы 🙌🏻 Ставим на X1,5 и приятного просмотра. 00:10 обсуждаем рынок ИТ 02:10 про выбор направления и переносимые навыки 04:30 на что обратить внимание, если не получается найти работу 05:00 разбираем, как составлять резюме 07:20 распространенные ошибки в резюме 14:15 что должно быть в резюме системного аналитика 22:10 про проверку резюме ATS 24:15 про стажировки как переходный этап 29:45 все главное про собеседования 32:10 оффтоп про тестовые задания и портфолио 33:40 как строить рассказ о себе 35:00 пример построения самопрезентации 40:30 про кейсы на интервью 42:00 технические вопросы на интервью 51:40 про силу софт скиллов 54:00 отвечаем на вопросы если нужна помощь с выбором направления, резюме и подготовкой к интервью, вам сюда.

Напоминалка о том, что встречаемся через час, в 13:00 МСК, чтобы поговорить про старт карьеры в ИТ в целом и в аналитике в частности.

Прямой эфир на тему карьеры Мне часто прилетают вопросы в комментариях и в личку ( всегда стараюсь отвечать) по моему менторскому опыту: как прийти в профессию, с чего лучше начать, про какие-то отдельные технические темы. Но так же много вопросов по построению карьеры в целом: что писать в резюме, почему дальше коммуникации с hr не заходит, как вести переговоры по ЗП и т.д). Поэтому появилась мысль провести совместный эфир с Олей - карьерным ментором и автором канала "Вопросы задаю Я", чтобы охватить волнующие всех темы. Я буду рассказывать со стороны человека, который проводит интервью и нанимает людей, а Оля со стороны HR и ментора, который как раз помогает подготовиться к процессу поиска работы. В итоге обсудим процесс с разных сторон, вы сможете задать вопросы и, надеюсь, всем будет полезно. План примерно такой: 1. Про рынок ИТ в целом. 2. Старт в профессии и поиск первой работы после обучения/переквалификации. 3. На что стоит обратить внимание: основные акценты в резюме и подготовка к интервью. 4. Ответы на вопросы. *мы не будем сужаться до системной аналитики, многие рекомендации аналогичные и для других направлений ➡️ Дайте знать, если вам такое интересно, и мы выберем дату проведения эфира. Еще будет круто, если вы заранее накидаете вопросы, которые хотелось бы обсудить.

🚩Красные флаги на собеседованиях Сегодня продолжим тему собеседований и поговорим о том, какие моменты на собеседованиях могут стать для вас звоночками о том, что вам не очень-то нужно в эту компанию. 1️⃣Пренебрежительное отношение интервьюера к кандидату Иногда мне рассказывают, как относятся на интервью, особенно к новичкам, и становится грустно, поэтому если: — к вам относятся не уважительно, без элементарной этики общения; — перебивают и не дают закончить фразы, сбивают с мысли; — комментируют ответы в негативном ключе: "ерунда какая-то", "что за бред ты несешь", "это вообще не так" (утрирую, но общий смысл понятен). Стрессовать и ошибаться на собеседовании - это нормально. Кстати, очень хороший показатель собеседования - когда вы ушли с него с большими знаниями, чем заходили. Лично я стараюсь всегда тратить лишние пары минут и давать правильные ответы на свои же вопросы. Да и практика показывает, что если уже на собеседовании происходят такие ситуации, то рабочий процесс будет сложным. Интервьюер - это лицо компании, который ее "продает" соискателю. У джунов есть выбор куда им пойти и иногда лучше потратить лишнюю неделю, две или даже три на поиски, чем на несколько месяцев работы в компании, которая вам не подходит. 2️⃣Плохая организация собеседования и процесса найма в целом — HR часто переносит встречи/меняются входные данные и вообще отсутствуют а-ля "все узнаете на собеседовании" — HR пропадает с радаров, не держит в курсе процесса или не отвечает на ваши вопросы долгое время; — Путают кандидатов\офферы для них\добавляются новые этапы собеседований, которые изначально не были оговорены. Скорее всего, это означает хаос в процессах компании. Как минимум в процессах найма, но кто может гарантировать, что точно таких же проблем не будет уже на вашем проекте? 3️⃣Слабый уровень технического собеседования Если вам почти не задают технических вопросов, спрашивают абстрактные вещи или собеседование проходит в очень рваном и непонятном ритме. Особенно, если интервьюер в целом не знает, что у вас спросить, потому что у него или нет плана собеседований или нет точного понимания, какой человек в команду нужен. Еще хуже, если у интервьюера самого мало опыта в целом. Это означает, что на проекте не будет эксперта по вашему направлению. что большой минус, потому что сильная команда помогает расти быстрее. *исключение, если вы сами уже сильный специалист, и готовы помогать расти другим. 4️⃣Нехватка ресурсов/постоянные переработки Переработки - это в целом частая проблем разных компаний. И если вас об этом спрашивают, то скорее всего это "тонкий" намек на то, что они есть на этом проекте. В этом случае нужно сразу спросить - оплачиваемые ли они. Если в ответ будет что-то про отгулы, какие-то доп. дни к отпуску и что угодно, кроме денег, хотя бы в х1.5 размере, то звучит неубедительно. Невозможно взять отгулы в команде, которая работает в режиме "кранч" (т.е. в авральном режиме) нон-стоп, потому что вам его просто не дадут взять (поверьте, я работал в таком режиме еще на второй линии поддержки). Если переработки оплачиваются, и вы не против заработать дополнительные средства на этом - welcome. Однако, тоже хочу заметить, что работать в таком режиме больше 2-3-4 месяцев подряд, в зависимости от ваших ресурсов, достаточно тяжело. 5️⃣Предлагают неофициальное трудоустройство/ серые схемы/ работу через ИП Тема спорная. Каждый решает сам, как относиться к этому. Но всё-таки одно из основных отличий работы в ИТ в том, что тут в 99.99% случаях вся работа идет в белую. Поэтому так ли нужно рисковать увольнением в любую секунду, проблемами с отпусками и отсутствием банального соц. пакета ради.. чего? Поэтому я не рекомендую способствовать развитию серой части бизнеса в ИТ. / Я еще обращаю внимание на то, как мне рассказывают про проект, задачи, команду. Всегда заметно, если человеку самому не особо то нравится то, чем он занимается, и это не добавляет энтузиазма. На что вы обращаете внимание при поиске работы? C какими флагами сталкиваетесь? Поделитесь своими историями.

📊Диаграммы. UML, часть 4. Диаграмма последовательности (sequence diagram) И, в конце концов, моя самая любимая - диаграмма последовательности. Хотя бы потому, что на практике, это одна из самых часто встречаемых схем. Как минимум потому, что с помощью нее можно достаточно быстро и понятно нарисовать любой интеграционный процесс (в основном для этого она и используется). Ну и кроме этого есть достаточно обширный пул применений, который ограничен лишь вашей фантазией и рабочей необходимостью. Диаграмма последовательности моделирует взаимодействие объектов на основе временной последовательности. Она показывает, как одни объекты взаимодействуют с другими в конкретном прецеденте. В UML под взаимодействием понимают обмен информацией. Схема последовательности построена таким образом, что она представляет собой временную шкалу, которая начинается сверху и постепенно опускается, чтобы отметить последовательность взаимодействий. Каждый объект имеет колонку, а сообщения, которыми обмениваются между собой, представлены стрелками. Объектом может быть как пользователь (можно вообще с помощью сиквенс диаграммы описать бизнесовое взаимодействия, без участия каких-либо систем. Но лучше для этого использовать BPMN всё же), так и система или ее часть. Сам процесс взаимодействия между объектами визуализируется с помощью стрелок. Они также бывают разных типов: ➖Синхронное сообщение. Отображается в виде обычной сплошной линии с закрытой стрелкой на конце. Так как это синхронное сообщение, то с помощью него мы показываем, что мы передаем управление процессом той системе, которую вызываем. И не можем продолжать работу до тех пор, пока не получим ответное сообщение; ➖Ответное сообщение. Отображается в виде пунктирной линией с открытой стрелкой. Является ответом на синхронное сообщение. Должно иметь противоположную направленность относительно синхронного сообщения (логично). Возвращает управление процессом системе; ➖Асинхронное сообщение. Отображается в виде сплошной линии с открытой стрелкой. Тут уже отправитель этого сообщения может не ждать ответа, т.к. не блокируется; ➖Рефлексивное сообщение. Отображается в виде сплошно линии с закрытой стрелкой, направленной из объекта в него же (п. 10 примера). Как правило отображает какое-то действие, которое выполняет система сама в себе, без вызова других участников взаимодействия (допустим, валидация запроса\ответа, какие-либо вычисления). Кроме этого, в рамках диаграммы последовательности можно: ➖Отображать комментарии поверх любых объектов или рядом с ними (п. 18 примера); ➖Объединять объекты\сообщения в группы, ➖Отображать параллельность действий; ➖Вложенность одно в другое и много еще чего. Воможностей для визуализации очень много. И в отличие от других типов диаграмм UML - диаграмма последовательности по большому счету очень простая для чтения и ее можно понять, даже если не знать всей теории. В следующих постах расскажу про то, какими инструментами можно пользоваться для того, чтобы проектировать UML-диаграммы и перейдем к BPMN. P.S. Очень жду вопросы от вас в комментариях по поводу тех тем, которые хотелось бы разобрать.