Пост

Не буду ходить вокруг да около, начну сразу, сегодня зашёл на сайт и хотел как и всегда сделать пост И ПОПАЛ В СТУПОР, от того что подумал, посмотрел и не смог выложить.

Я тут новичок ещё и не известно какой формат лучше, какой лучше заходить но и не в этом дело.

хотел выложить очередную статью "из серии реальная история из жизни", но пролеснув все свои посты понял что такие длиннопосты тут ни кому не нужны😢

ВОПРОС: так стоит или нет заливать длинные статьи? или не парится и разбить эту историю просто на посты с картинками?

За ранее всем спасибо большое, за вашу помощь😉

Как рост персонажей влияет на восприятие в аниме, манге и ранобэ: Полное руководство
Введение: Почему рост так влияет на восприятие?
Когда мы впервые встречаем персонажа в аниме или на странице манги, наш мозг за доли секунды обрабатывает сотни визуальных сигналов. Один из самых мощных, но часто недооцененных — рост. Это не просто техническая характеристика в профиле персонажа. Рост — это рассказчик, инструмент построения иерархии, маркер взросления и даже скрытая метафора.
В японской поп-культуре отношение к росту отличается от западного. Если на Западе высокий рост традиционно ассоциируется с маскулинностью и лидерством (супергерои вроде Супермена или Тора), то в аниме и манге все гораздо сложнее. Здесь двухметровый персонаж может быть комичным неудачником, а 150-сантиметровый — вселенским злом. Почему? Давайте разбираться.
Часть 1. Что такое рост персонажа в контексте визуального повествования?
Рост персонажа — это не только его физическая высота в сантиметрах или футах. В мире аниме и манги это понятие включает в себя три ключевых аспекта:
1. Абсолютный рост — официальное значение из databook (справочников) или эпизода. Например, Леви Аккерман — 160 см, а его сюзерен Эрвин Смит — 188 см.2. Композиционный рост — как персонаж выглядит на фоне других в конкретной сцене. Из-за особенностей ракурсов и стилизации (аниме-головы часто непропорциональны) один и тот же персонаж может казаться то карликом, то гигантом.3. Символический рост — изменение роста (физическое или метафорическое) по ходу сюжета, когда персонаж «вырастает» из своей старой роли.
Режиссеры и мангаки используют эти три уровня комплексно. Например, в «Наруто» главный герой долгое время показан ниже большинства сверстников (стартовые 145 см против 166 см у Саске), что визуально подчеркивает его статус «выскочки-неудачника».
Часть 2. Как рост определяет характер и архетип персонажа?
Создатели сериалов давно вывели статистические закономерности. Зная рост персонажа, можно с высокой вероятностью предсказать его роль в сюжете.
Шорт-кинг (низкий персонаж): 150–165 см
· Примеры: Леви (Атака Титанов), Гоку (Драгонболл, 160 см во взрослом возрасте), Эрен Йегер (170 см, но часто ниже своих оппонентов).· Черты: Сверхкомпенсация, взрывная сила, комплексы, ставшие топливом. Низкий рост здесь — обманка. Противник расслабляется, думая, что перед ним ребенок, а получает ураган ярости. Восприятие зрителя: «Бойся маленького».· Эффект: Зритель постоянно ждет от такого героя подвига, чтобы доказать «миру» свою крутость.
Средний «нормальный» рост: 166–175 см
· Примеры: Спайк Шпигель (Ковбой Бибоп), Лайт Ягами (Тетрадь смерти), Ринго (Дуралей).· Черты: Баланс, скрытность, способность затеряться в толпе. Это рост «серого кардинала». Он не привлекает внимания, что идеально для манипуляторов и стратегов.· Эффект: Зритель воспринимает такого героя как «своего», реалистичного. На его фоне высокие кажутся карикатурными монстрами, а низкие — эксцентриками.
Высокий и очень высокий: 180–200+ см
· Примеры: Кисуке Урахара (Блич, 190 см), Дзюзаро Наойе (Bleach, 200+), Ода Нобуна из многих исекаев.· Черты: Угроза, отцовская фигура, либо абсолютный пацифизм (великаны-добряки). Интересно, что в современных сёнэнах высокий герой редко бывает главным злодеем. Чаще — учителем, охраняющим границу, или комическим гением.· Эффект: Высокий персонаж создает вертикальное напряжение. Камера всегда смотрит на него снизу вверх, что давит на зрителя.
Экстремальный рост (> 2,2 м или < 130 см)
· Примеры: Чудовище (Монстр), Нико Робин в детстве (Ван-Пис), Акаин (Семь смертных грехов).· Черты: Дегуманизация. Либо персонаж перестает ощущаться как человек (становится монстром или божеством), либо его рост — трагедия (изгой из-за непохожести).
Вывод: рост кодирует ожидания. Увидев крошечного персонажа в очках, зритель ждет интеллекта (Лилу Даль, Паразит). Увидев верзилу с бейсбольной битой — ждет насилия.
Часть 3. Как рост влияет на восприятие отношений: динамика «выше-ниже»
В романтических и дружеских сюжетах разница в росте — это отдельный язык флирта и конфликта.
1. Доминирование / Подчинение
Когда герой смотрит на героиню сверху вниз — это классический патриархальный код (например, Харухи Фудзиока и Каору из «Бесплатно!», хотя там сложнее). Но в обратном случае (девушка выше парня — «Тада-кун не влюбляется», «Любовь как проливной дождь») — разрушение стереотипов. Восприятие: Нежность, защита слабого, либо фемдон (женское доминирование).
2. Конфликт как баскетбол
Помните битвы в «Наруто» между Минато и Обито? Разница в росте меняет хореографию боя. Низкий персонаж атакует снизу вверх (слабость ног противника), высокий — сверху вниз (уязвимость макушки). Это влияет на то, как зритель оценивает угрозу: удар сверху кажется более фатальным и театральным.
3. Эмоциональная близость
Сцена, где высокий герой опускается на колени, чтобы оказаться на уровне глаз плачущей героини, работает в 100 раз сильнее, чем если бы они были одного роста. Это жест ритуального самоуничижения. В аниме этот прием используют постоянно («Клинок, рассекающий демонов», Тандзиро и Нэдзуко).
Часть 4. Канон и фан-сервис: Как определяется рост официально?
В Японии существует культ персонажных профилей. Каждое мало-мальски серьезное аниме публикует Fan Book или Databook, где рост округляется до целого сантиметра (иногда до миллиметра, как у Боа Хэнкок: 191 см). Но эти данные часто противоречат кадру, потому что:
1. Аниме-пропорции: У персонажей длинные ноги и маленькие головы, не как у людей. Если строго соблюдать scale, дверные проемы пришлось бы рисовать заново в каждом кадре.2. Абсолютная величина: Создатели указывают рост просто для вики. На экране же значение имеет только контраст с ближайшим объектом. Если персонажа надо сделать жалким — рядом поставят гиганта. Если крутым — выделят на фоне лилипутов.3. Канон выше логики: В «Ван-Пис» рост постоянно «плавает». Чарльз Эрик 3 метра, но в одной сцене он в два раза выше корабельной мачты, в другой — едва дотягивается до люстры. Это называется «dramatic height» — драматический рост, подчиненный настроению момента.
Как измеряют рост персонажей в манге?
Художники используют «головы» (как в академическом рисунке).
· 6 голов — детский / комичный рост (Чиби).· 7 голов — средний подростковый (сёнэн-герои).· 8 голов — брутальный взрослый.  Если персонаж внезапно начинает рисоваться в пропорциях 8 голов вместо 7 — значит, сюжетно он повзрослел. Это не физический рост, но визуальный — один из мощнейших приемов таймскипов (таймскип в «Наруто»: рост Сакуры с 162 до 165 см незначителен, но пропорции изменились коренным образом, она стала выглядеть старше).
Часть 5. Пол персонажа и рост: разрушая мифы
В западных медиа женщина выше мужчины — это либо комедия, либо драма. В аниме — норма. Возьмем «Атаку Титанов»: Микаса Аккерман (176 см) выше большинства мужчин-кадровых солдат, включая Армина (162 см). И зритель воспринимает это не как «странную пару», а как данность: Микаса — сильнейший воин, её рост подчеркивает физическое превосходство.
Аналогично в «ДжоДжо: Стальные шары»: Стив Стил — карлик, а его жена Люси — подросток выше его ростом, но именно она доминирует в паре.
Таким образом, в аниме и манге корреляция «рост=сила» строго работает только внутри одного пола. Межполовой рост — это зона свободной игры, где социальные стереотипы часто нарушаются нарочно, чтобы вывести читателя из зоны комфорта.
Часть 6. Ранобэ (книги): Как рост работает без картинки?
В текстовых ранобэ рост описан бессилен — там нет картинки. Но писатели придумали обходной путь: эффект привязанного сравнения.
Вместо «он был 190 см» автор напишет: «Ему пришлось пригнуться в дверях казармы, построенной для обычных солдат». Или: «Когда она вставала на цыпочки, её макушка едва доставала до его плеча — разница была как между господином и слугой».
В ранобэ рост превращается в гаптический код (тактильный). Читатель «чувствует» разницу через детали окружения:
· Руке приходится тянуться слишком высоко для выключателя.· Во время объятий лицо упирается в грудную клетку, а не в плечо.· Тень собеседника полностью накрывает героя.
Поэтому в текстовых новеллах рост даже выразительнее, чем в аниме: мозг дорисовывает самые драматичные вертикальные контрасты.
Часть 7. Психология восприятия: Почему нас задевают маленькие герои?
Исследования показывают: зритель подсознательно ассоциирует экранный кадр с собственным телом. Когда камера смотрит на персонажа снизу, зритель чувствует себя ребенком, а персонажа — взрослым авторитетом. Когда сверху — наоборот, чувствует превосходство.
Аниме манипулирует этим без стыда. В «Тетради смерти» почти все сцены с Лайтом (179 см) сняты с уровня его плеч, а сцена с Божком смерти Рюком (230 см) — с пола. Разница в восприятии заставляет нас бояться Рюка, даже когда он шутит.
Более того, канонически низкий протагонист (Эрен, 170 см) вызывает больше эмпатии, чем высокий. Потому что мы сами редко бываем самыми высокими в комнате. Маленький герой — это мы в подростковом возрасте: неуверенные, злые на несправедливость размеров мира.
Часть 8. Ошибки авторов и как рост ломает иммерсию
Даже великие мангаки ошибаются. Главная проблема — бесконтрольный масштаб. Например, в длительных сериалах («Блич», «Ван-Пис») к 300-й главе рост героя-ребенка забывают и рисуют как взрослого, хотя канонически прошло 2 месяца сюжетного времени.
В ранобэ ошибка — это гиперописания. Когда автор на каждой странице напоминает, что героиня на 15 см ниже героя, это начинает раздражать: читатель и так запомнил. Хороший тон — упомянуть рост единожды в первой трети книги, а затем использовать контекст (полки, рукопожатия).
Заключение: Рост как сюжет, а не как галочка
Рост персонажа — это не строка в вики-энциклопедии. Это динамический инструмент, который:
1. Создает молчаливую иерархию без слов.2. Маркирует взросление (таймскип + 10 см = новый статус героя).3. Управляет эмоциональным давлением сцены.4. Ломает (или укрепляет) гендерные стереотипы.
В следующий раз, когда вы будете смотреть баттл-сцену или романтическую комедию, обратите внимание: где находится подбородок собеседника относительно глаз героя? Кому приходится запрокидывать голову? Это не случайно. Ростом управляют так же тщательно, как цветом волос или длиной меча. И возможно, именно в этой разнице сантиметров скрыта настоящая магия аниме.

Что почитать/посмотреть на эту тему (рекомендации):
· «Атака Титанов» — лучший учебник по контрасту роста (3-15 метровые титаны против 160 см Леви).· «Клинок, рассекающий демонов» — как Тандзиро (165 см) физически преодолевает рост демонов.· Ранобэ «Восхождение Героя Щита» — навязчивая тема роста Наофуми и Рапталии (от 154 до 168 см через 10 томов).· Видео-эссе «Anime Height and Power Dynamics» на YouTube.

Если что в блоге не кого не хотел оскорбить, заранее приношу извинения если что.

Всем привет.

UPD. Опять получился длиннопост с большим количеством текста в формате моих пояснений - простите, но не представляю как по-другому можно что-то объяснить, вроде стараюсь не графоманить.

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

Шаблонов, на самом деле много и от команды к команде отличаются. Где-то СА просто пишут, что "метод должен получать объект User из базы Users и дальше отдавать его вызывающей стороне" - и это вся постановка. В каких-то командах упарываются и пишут ТЗ на микросервис целиком, в связке статьи в git в формате asciidoc + swagger (yes, I like it и отдельно про это тоже расскажу).

Но в большинстве случаев принято что-то среднее между этими крайностями - системному аналитику важно описать следующее:

1. То, какие данные метод получит на вход и правила валидации для них;

2. То, что метод должен сделать с этими данными, т.е. какую бизнес-логику выполнить;

3. То, что метод должен вернуть в ответ вызывающей стороне.

Допустим, нам нужно описать какой-нибудь метод, который получает любую бизнес-сущность по ее идентификатору.

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

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

Теперь по шагам:

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

2. URI или URL метода. Состоит из одного из типовых глаголов плюс сам путь, по которому данный метод будет доступен. Про всякие best practices нейминга расскажу отдельно, в комментариях под предыдущим постом спрашивали;

3. Разрешения или Permissions. Если у вас есть ролевая модель и вам нужно разграничить доступ к каким-либо ресурсам среди пользователей с разными ролями - то вступает в дело данная строка таблицы. В ней нужно перечислить те роли, у которых есть доступ до данного метода;

4. Параметры запроса, который должны (или могут) быть переданы на вход данного метода. Т.к. у нас очень простой метод, то у нас их нет. Единственный атрибут в виде идентификатора пользователя ( ) передается напрямую в ссылке. Т.е. пример запроса будет просто выглядеть вот так: GET /users/22 - дай мне пользователя с идентификатором 22.

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

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

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

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

На этом примере - у вас стоит бизнесовая задача (например): есть админка со списком пользователей, администратор нажимает на какую-то конкретную карточку пользователя, с целью просмотреть всю информацию по нему - в этот момент, как раз фронт откроет отдельную экранную форму и вызывает наш метод, передавая туда идентификатор искомого пользователя (который он ранее получил из другого метода, который получает массив пользователей, что-то вроде GET /users), чтобы получить всю нужную информацию для отображения.

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

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

Ну и всегда (по моему мнению), во всех методах нам нужно валидировать входящий запрос до того, как начать основную бизнес логику. Потому что зачем нам это делать и тратить драгоценное время и ресурсы, если мы заранее знаем, что запрос не валиден? Т.е. как минимум нам нужно проверить rq на соответствие контракту, что все обязательные атрибуты пришли и пришли в корректном формате. Как максимум выполнить еще всякие кастомные валидации, по типу тех же проверок на роли.

Также заранее поясняю, что в ответе ссылка на объект User (пользователь) ведет на описание атрибутивного состава объекта (в моем примере в конфлю нет, потому что я этого не сделал, но на боевых задачах - да), поэтому не нужно расписывать и дублировать этот объект еще и тут. Однако, если вам нужно передать не весь объект, а только его часть, например, не возвращать на фронт какие-то пароли пользователей или другие конфиденциальные данные, чтобы их не "схачили" - то нужно отдельно это указывать.

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

P.S.: По традиции - буду признателен за вопросы про карьеру\профессию\чему угодно связанному со сферой IT - постараюсь ответить на всё.

P.P.S.: Также веду телеграмм-канал, в котором делюсь разным про профессию и про свой путь в ней. Есть и хардовая информация (асинхронные, синхронные интеграции, примеры ТЗ\шаблонов написания микросервисов), так и более софтовая - см. закрепленный дайджест.

Всем привет.

Небольшое предисловие. Я осознаю, что этим постом я вступаю на охрененно тонкий лёд. Если уж к моему предыдущему посту были претензии за то, что я посмел использовать HTTP 404, то уже интересно, какие комментарии последуют после выхода этого поста, в любом случае - you are welcome!

Но тут стоит уточнить, что все те подходы (разные), по которым мы проектируем сервисы - они разные как раз потому, что нет единых mandatory правил к архитектуре приложений, которым если не следуешь - твоя система ломается и больше никогда в жизни не заработает, даже если ты исправишь ее. Есть лишь РЕКОМЕНДАЦИИ, а их многие интерпретируют по-разному и это тоже нормально. Для кого-то свойственно не использовать коды ошибок вообще и передавать их в теле ответа с HTTP 200, для кого-то нет. Ни один из этих подходов не является не правильным.

И нет никаких технических ограничений в принципе. Ты можешь спокойно использовать метод GET для удаления объекта, если ты его так напишешь (не делайте так) или использовать метод PUT, вместо POST, для создания объекта (так уже можно, если понимаешь почему). Главное, чтобы ты понимал как эти тонкости реализации правильно применять. Если сомневаешься - используй методы по классике, хуже от этого он работать не будет.

Да, можно уже прям сейчас кидать тапками.

Теперь уже к основному телу сабжа. Сейчас расскажу про ряд лучших практик, которые можно применять. @VRock, ты как раз спрашивал по поводу конвенции о наименовании ресурсов, тут про это тоже будет.

1. Имя endpoint'а - это существительное, а не глагол. Это одна из самых распространенных ошибок, которые я когда либо встречал (и сам совершал, естественно). Например, было в моей практике и такое - POST /generateMultipleDocument.

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

В идеале, в данном варианте будет POST /documents

Не везде от этого можно избавиться, но в большинстве случаев всё-таки можно, если потратить время на придумыванием вариантов (опять же - по факту нейминг ни на что, кроме красоты и структурированности вашего проекта не влияет. А на сколько это важно - решать вам или вашей команде).

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

Если же нужно указать, что из всего массива экземпляров ресурса вам нужно получить\обновить\удалить какой-то конкретный, то помещайте идентификатор этого ресурса в URL, передавая его в path.

Например, вот так:

/documents

/documents/

Вместо:

/document

/document/

1.2. Используйте "/" для обозначения иерархии и в принципе используйте вложенность ресурсов.

Например, если мы именуем наш ресурс, как users//playlists//songs - это значит у мы хотим работать со всеми песнями, конкретного плейлиста конкретного пользователя. И сразу понятна иерархичность этих ресурсов.

1.3. Не используйте "/" как закрывающий символ вашего URI.

Вариант users//playlists//songs сильно лучше, чем users//playlists//songs/

1.4. Используйте "-" для разделения составных слов.

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

Поэтому вместо /applications//creditcardhistory, куда лучше использовать /applications//credit-card-history.

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

Например:

host/v2/documents вместо host/v1/documents после внесения мажорной доработки.

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

В случае если был полный или частичный рефакторинг, менялись обязательные параметры (например, добавлен новый атрибут, который является обязательным), возможно при добавлении нового метода (тут вопрос к разработчикам, в этом случае тоже мажорная версия повышается или т.к. это не влияет на работу подписантов то пофиг?) - инкрементируется мажорная версия.

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

Однако, это не всегда обязательно - в случае, если появляется такая мажорная доработка, но ваши подписанты не готовы дорабатываться одновременно с вами (причин этому может быть множество) - вы можете выкатить одновременно две версии микросервиса, v1 и v2 и поддерживать их обе. Те, кто доработался будут использовать v2, остальные предыдущую версию. Это несет неудобства и затраты, но в любом случае лучше, чем допускать неработоспособность интеграции. В дальнейшем, когда все ваши подписанты доработаются - поддержку предыдущей версии можно остановить.

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

3. Используйте пагинацию.

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

Поэтому принято выполнять пагинацию таких данных (от слова page - страница), т.е. возвращать ему часть всей коллекции в каждом запросе. Например - 15, 30, 50 элементов + информацию о текущем положении полученной информации в общей выборке. Почитать про это можно более подробно где-нибудь тут (первая попавшаяся ссылка, я не вчитывался, не реклама).

4. Используйте коды ответов HTTP правильно и эффективно.
Их достаточно много (https://developer.mozilla.org/ru/docs/Web/HTTP/Status) и их можно использовать по назначению. Все знать и использовать не обязательно, но вот примеры их использования

Использовать 201 "Created", вместо 200 "OK", в случае если вы в POST действительно создаете какой-то ресурс. Используется только в POST (ну и в PUT, в ряде частных случаев).

Использовать 204 "No Content", вместо 200 "OK" для DELETE. Это ответ на успешный запрос и он не будет возвращать тело, что и не нужно для данного метода.

Не забывайте использовать 401 "Unauthorized", 403 "Forbidden" и 404 "Not found" вместо безликого 400 "Bad Request", когда это уместно. Как правило 400 кодом пользуются когда нужно ответить на какую-то ошибку валидации или в случае возникновения бизнесовой ошибки, которую вы заранее можете предсказать (очень настоятельно рекомендую хотя бы дополнять код ответа еще и кодом бизнесовой ошибки в этом случае и желательно ее текстом (error.code и error.message соответственно).

Для валидации желательно тоже).

А для всего остального можно и специальные коды использовать.

P.S.: По традиции - буду признателен за вопросы про карьеру\профессию\чему угодно связанному со сферой IT - постараюсь ответить на всё.

P.P.S.: Также веду телеграмм-канал, в котором делюсь разным про профессию и про свой путь в ней. Есть и хардовая информация (асинхронные, синхронные интеграции, примеры ТЗ\шаблонов написания микросервисов), так и более софтовая - см. закрепленный дайджест.

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

Тут такая история случилась: выложила я очередной пост про секс-игрушку, попался он на глаза @Dr.PerryCox и человек от души, но вполне культурно комментарий написал. На Пикабу ведь как бывает - пост выложишь и отвлечёшься на пятнадцать минут. Возвращаешься, а там уже пепелище, развалины дымятся, пикабушники друг другу головы пооткусывали и тебе заодно глаз подбили. Профилактически, чтобы не забывал, кто тут главный.

А тут всё в рамках приличия - высказал человек своё мнение, мы в обычном порядке немного сцепились, но Пикабу и не такое видал. Я честно, пропустила момент, когда история получила продолжение, потому что комментарии @Dr.PerryCox исчезли и по его словам он получил эцих с гвоздями бан от модераторов сообщества NSFW Познавательный.

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

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

Так вот, вопрос в студию - в какое Спортлото писать, чтобы человеку вернули его комментарий и вынули @Dr.PerryCox из эциха? , NSFW Познавательный, можно вернуть всё как было? Если по уставу оптом нельзя, то хотя бы комментарий ему назад отдайте, а то сидит человек, расстраивается.

P.S. Если что, я запомнила, кто на меня модераторам ябедничал. )

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

Для тех, у кого есть вопросы - можно писать в телеграм @SexFox_1.
Это не канал, а просто средство связи.
Для тех, кто не хочет задавать вопросы в комментариях. Могу ответить не сразу, потому что иногда в два слова не уложишься, почти каждый ответ - развёрнутый и подробный. Его написать нужно сначала, а по ночам я вообще сплю иногда. Но это не точно. )

И я никогда не думала, что сделаю это, но:

Мой канал в телеграм - SexFox.

Почему появился?
Потому что сотворить интересного на квадратный сантиметр времени у меня получается много, а писать посты - это вам не воробьям фигушки крутить. Да и достоин ли каждый шаг пусть и несравненной SexFox того, чтобы писать о нём пост? Если что - это сарказм.

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

Ссылка на канал будет в шапке профиля, плюс бесить всех в конце постов (хе-хе).

Зачем появился?
Да чтобы интересно было (надеюсь) и на Пикабу оставить базу, а в телеге лапы разминать. Вы же мою продуктивность знаете.

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

Недавно завирусилась история о том, как кандидат вписал себе в резюме фиктивных два года опыта и прошел интервью на позицию в ИТ-компанию. Правда потом об этом узнали, и его вроде как уволили. Я не придал этому значения, пока мне не рассказали, что в одной онлайн-школе этому прям учат студентов, такая вот "гарантия трудоустройства". А на днях в одном из hr-чатов выложили фейковое резюме тестировщицы с 2 годами опыта, которая не смогла ответить ни на один технический вопрос.

В общем, весь этот треш оказался ближе, чем кажется. Не буду рассказывать, что обманывать нехорошо. Но я обратился за рекомендациями  к Оле - HR в ИТ, карьерному консультанту и автору канала про карьеру, с которой мы трудоустроили уже ни один поток моих учеников.

Далее от ее лица.

Итак, последствия таких обманов могут быть разными:

(1) резюме могут закинуть по разным чатам и потом, чтобы найти работу, придется менять еще и фамилию (внутри одной сферы обычно тесно общаются и репутация дорога)

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

(у меня, кстати, был случай, когда клиентке отказали на последнем этапе из-за того, что данные из анкеты не совпали с реальностью)

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

!(4) и что-то новенькое: hh.ru, на котором размещаются резюме, начал проверять точность информации и связываться с работодателями.

Поэтому поговорим о том, как можно привлечь внимание к себе, чтобы потом не уволили, как в этом случае:

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

(2) Использовать нетворкинг - знакомиться с людьми, которые работают в тех компаниях, куда вы хотите. Даже просто написать и попросить зарефералить. Теория с рукопожатиями тоже работает (у меня так много клиентов и знакомых нашли работу)

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

(3) Резюме должно быть продумано до мелочей, из самого базового:

➡️ название должности должно соответствовать названиям вакансий, т.е не "специалист", а максимально конкретно;

➡️на первом месте должен быть опыт по той вакансии, на которую вы хотите, даже если это учебный опыт;

➡️ расписать подробно навыки, которые вы получили на обучении, лучше сразу с примерами из практики.

(4) Брать из предыдущего опыта все навыки, которые могут быть полезны. Смена направления — это не начинать с нуля, всегда есть переносимые навыки. Например, опыт ведения коммуникации и работа в команде, который есть у всех, и другие soft skills. Успех поиска 50/50 зависит от hard и soft skills.

(5) Использовать сопроводительные письма и писать вдумчивые отклики на позиции (спам-рассылка скорее всего не даст результата). А вот резюме + нормальное сопроводительное можно отправлять не только на hh, но и напрямую в компании, даже если вакансии нет, вас могут добавить в базу и написать позже.

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

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

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

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

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

Автор описания - Kim, байкпост.

Предупреждение: текст написан мотоциклистом и для мотоциклистов. Хотя соблюдение таких правил мотоциклистами будет полезно и для автомобилей, в первую очередь это вопрос взаимодействия мотоциклист-мотоциклист. Автор - Sanches_RSC. Далее - его текст. Внимание, копипаста!

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

Новички наматывайте на ус, опытные дополняйте.

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

Всё очень просто – один мотоциклист объезжает машину слева, второй справа, двигаясь параллельно. Всё действие происходит в пределах одной полосы. Водитель коробки слышит звук мотоцикла, кидает взгляд в левое зеркало и видит приближающийся мотоцикл. В правое зеркало он не посмотрит, ведь он уже увидел источник шума слева. При этом впереди, в лобовое стекло, он видит, что справа есть около метра до машин следующего ряда. Так что в правое зеркало ему (по его мнению) смотреть просто незачем. Он резко сдаёт вправо, освобождая междурядье и… правильно, сносит едущего параллельно справа. Вот личное видео, где кгхм… пип-пип [censored] мотоциклист сильно подставил мотобратьев и только чудом это не привело к аварии.

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

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

Не совсем про мотоциклистов, но похожая ситуация и с машинами специальных служб, едущих в пробке с включенной сиреной. Водители машин их пропускают, междурядье сдвигается, а там ты. И в рёве сирены твой прямоток никто не услышит. Видишь скорую\полицию, двигающую твоё междурядье – или на газу обгоняй их и уходи сильно вперед (моц один хрен быстрее любой мигалки в пробке, проверено) либо сместись опять-таки через два ряда, как описано выше. Я рекомендую второй вариант – особо правильные водители, услышав сирену, могут начать перестраиваться задолго до фактического приближения скорой. А тут ты…

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

2. Пропусти быстрого.

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

Медленному:

Едешь в междурядье – мониторь зеркала. Сзади может подкрасться быстрый мотобрат. Без спешки, суеты и опасных для тебя маневров спокойно двигаясь с той-же скоростью дождись появления сбоку «кармана” среди коробок, куда можно уйти и пропустить его. Включи поворотник, сдвинься туда и обозначь, что пропускаешь – махни рукой в освободившееся междурядье или просто сместись максимально вбок, давая понять, что ты пропускаешь.

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

Быстрому:

Не будь быдлом, смотри выше про братство. Если тихоход в междурядье всё не уступает дорогу — тому может быть несколько причин. Возможно он, см.выше, “без спешки, суеты и опасных для тебя маневров спокойно двигаясь с той-же скоростью” ищет карман, чтобы тебя пропустить. Подожди, тебя ведь не прельщает дурная «слава» кортежей членовозов, от которых презренная челядь “должна” в спешке и панике разбегаться в разные стороны? Мотобратан пропустит, просто обожди. Потеряй уж пять секунд своего драгоценного времени, но не потеряй лицо.

А может тебя просто не видят. В этом случае обозначься – рявкни трубой, но не настойчиво, сгоняя, а коротко. Типа – “Я тут, бро. Мне бы проехать, если ты не против.” Смотри на его зеркала – если видишь взгляд пилота, значит тебя увидели.

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

Если тебя ну никак категорически не пропускают… Ничего, бывает и такое. Человек не знает этих правил, ездить не умеет и боится лишних маневров, считает что он тебя быстрее… Да пофиг, он тебе ничего не должен, в конце-концов. Это просто правила приличия. Обгони. Но сделай это безопасно, через два ряда (см.правило №1). Ну в конце концов, обгон всегда был проблемой обгоняющего. И если ты такой мотогонщик, то и не забывай – на треке тоже никто никого не пропускает. Умеешь ездить – не дави на нервы, не виси на заднем колесе, не сгоняй с пути прямотоком или дальним светом, а технично и безопасно обгони. На то ты и «спортсмен”. Не можешь? Значит ты и не спортсмен, езжай спокойно за ним, рано тебе еще гонять.

Один раз мне на хвост в пробке упал на заднее колесо, прям впритык, какой-то спорт. При том, что ехал я довольно бодро. Рычит трубой. Ну ладно, спешит человек. В роддом там, или может на пожар. Вижу “карман”, собираюсь туда уйти и пропустить и тут… Это кретин, на диком газу и миллиметражах, обгоняет уже смещающегося вбок меня через этот “карман”. Ну не урод ли? Не уподобляйтесь, мы – другие.

UPD:

Вот еще видео на эту тему, от уважаемого MRIDOC

3. Не виси на хвосте ведущего.

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

Да ты первого из цепи даже не видишь, так как идёшь в метре от заднего колеса предпоследнего. А вдруг это, например, свежий спорт с комбибрейком, “синтетическими” колодками, на мягких свежих “мишках»-“пирельках” и с двумя трехпоршневыми суппортами и двумя тормозными дисками только на одном переднем колесе? Твоя 400-я сибиха на прошедшей три сезона бюджетной резине правда успеет оттормозиться, если он вдруг резко «даст по тормозам»?

Держите дистанцию! Метров 7-10 между мотоциклами вполне достаточно для оттормаживания в большинстве возможных случаев в междурядье. Да и если у тебя самого хорошие тормоза – при попадании ведущего в открытую дверь автомобиля, например, тормозного пути просто не будет. Он рухнет там же, прямо на твоем пути.

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

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

Притормаживай перед междурядьями! Верти головой, не доверяй зеркалам. Ну может там летит кто шустро, тебя не видя. Не все же ездят по крайнему левому междурядью. Да и ему, может, надо в тот-же поворот. И ты его не увидишь в крохотное зеркальце среди коробок. Прямо перед следующим междурядьем, не перекрывая его, обернись. Посмотри именно между машин, когда они не перекрывают обзор.

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

5. Старайся ехать в крайнем левом междурядье.

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

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

Если ехать в других междурядьях, то может срабатывать правило №1. Большинство мотобратанов будут ехать в крайнем левом и сдвигать на тебя, плетущегося через ряд, автомобили. По вышеизложенным причинам и с чисто практической точки зрения крайнее левое междурядье самое широкое и «проходимое» для моца.

Отсюда вывод — если в крайнем левом междурядье нет какого-то трэша (двойной разметки на реверсивках, рельсов, итд) — при прочих равных старайся ехать там. Не хочешь там ехать — см. правило №1 и смещайся через ДВА ряда в бок.

Всем мотобратухам и мотосеструхам — мир! Уважайте друг друга.

Всем привет.

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

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

Виды требований.

Общепринято делить требования на следующие категории:

• Функциональные требования, которые включают в себя:

  • Бизнес-требования - что система должна делать с точки зрения бизнеса. Т.е. содержат в себе высокоуровневые задачи и цели заказчика. Как правило их формулируют именно те люди, которые заказывают какой-либо продукт. Они описывают те цели, которые заказчик намеревается достичь с помощью системы (ПО). В 90% случаев эти требования направлены на получение дополнительной прибыли заказчика:

    • Либо через внедрение доработки\системы, которая будет приносить прямую прибыль через, допустим, привлечение новых клиентов (привет ДБО и различные мобильные приложения);

    • Либо через сокращение издержек и оптимизацию процессов, что тоже приводит к увеличению прибыли;

    • Либо по необходимости. Например, когда центробанк выдал на-гора очередное распоряжение по необходимости считать ПДН (показатель долговой нагрузки) клиента - банкам ничего не остается делать, кроме как внедрять соответствующие доработки. Ну тут тоже есть косвенная финансовая выгода: ты делаешь доработку > не получаешь штрафы и не теряешь лицензию > профит.
      Пример бизнес-требования: “Требуется уменьшить время работы над одной заявкой сотрудником колл-центра на 50%” (чувствуете прямую выгоду? Быстрее обработка > больше заявок будет обработано в единицу времени > дешевле стоимость обработки или просто выше КПД).

  • Пользовательские требования описывают цели и задачи, которые пользователи смогут решить с помощью системы. Их часто представляют в виде сценариев использования (Use case, о которых поговорим позже).

  • Функциональные требования (системные) - определяют функциональность (поведение) программной системы, которая должна быть создана разработчиками для предоставления возможности выполнения пользователями своих обязанностей в рамках бизнес-требований и в контексте пользовательских требований. Другими словами, что должны сделать разработчики, чтобы по итогу получилась система, позволяющая пользователь выполнять их функционал и выполняющие бизнес-требования заказчика.
    Например, “Требуется реализовать возможность поиска товара по продавцу, категории, диапазону сумм и рейтингу”.

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

  • Бизнес-правила - описывают почему система должна работать именно так в разрезе внутренних корпоративных правил, требований закона и различных стандартов.
    Например, многие табачные компании и компании, производящие алкоголь, требуют постоянного доказательства того, что промо-сайтами пользуются люди, достигшие определенного возраста. Это бизнес-правило (подтверждение возраста) возникает по требованию этических комитетов заказчика, хотя и несколько противоречит маркетинговым целям и требованиям по usability;

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

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

    Например, "Требуется ограничить загрузку файлов размером более 20мб", "Ограничить работу приложения только на IOS" или только в браузере Chrome и т.д.

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

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

На схеме это выглядит примерно вот так:

Качества требований:

С видами требований разобрались. Теперь нельзя обойти стороной вопрос о том, а какими они должны быть, эти требования? Вот список качеств, которыми требование, очень желательно, должно обладать:

• Атомарность - требование является атомарным, если его нельзя декомпозировать на несколько требований. Например, “Требуется ограничить загрузку файлов размером более 20мб” является атомарным, т.к. его нельзя разделить на несколько частей;

• Завершенность и полнота - требование содержит полный набор информации для однозначного понимания;

• Краткость - чем лаконичнее требование, тем лучше;

• Консистентность - требование не должно противоречить самому себе и другим требованиям;

• Выполнимость - требование возможно реализовать в рамках проекта (его сроков и бюджета);

• Проверяемость - реализованность требования может быть определена через один из четырёх возможных методов: осмотр, демонстрация, тест или анализ;

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

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

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

P.S.: Опять получился длиннопост, но скорее всего все последующие будут примерно такими же, т.к. на самом деле темы объемные и уместить все что хочется (и необходимо) рассказать в одном посте достаточно тяжело.

P.P.S.: Буду признателен за вопросы про карьеру\профессию\чему угодно связанному со сферой IT - постараюсь ответить на всё.

Всем привет, меня зовут Сергей, я ведущий системный аналитик в IT с опытом более 7 лет, в основном, в различных крупных ФинТех проектах и в заказной разработке. Хочу поделиться своим опытом тут, на Пикабу (видимо, наступила пора не только читать, но и писать и постараться принести этим пользу сообществу).

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

Системный аналитик - это связующее звено между заказчиком, каким бы он не был, и технической частью команды разработки. Если очень коротко - то его главная цель преобразовать обширный, и порой такой непонятный язык бизнес-заказчика в конкретные, выверенные требования. Т.е. уйти от "Я хочу получить свой сайт с функционалом маркетплейса.. ну как вон там, у ОЗОН" и прийти к "Требуется разработать систему.." и тут ТЗ на *дцать страниц.

Т.е. результатом работы СА становятся формализованные требования в формате ТЗ или любом другом принятом на проекте виде (это могут быть просто набросанные в Jira или Confluence предложения, являющиеся требованиями. Т.е. не нужно пугаться, что это прям всегда огромные, сложные и зубодробительные документы по ГОСТу, как дипломная работа - как раз этого почти и нет, разве что на каких-то госпредприятиях).

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

И что самое интересное и важное лично для меня в этой профессии, что тут можно (и нужно) реализовать как свои творческие, так и свои технические способности, потому что она находится на стыке этих двух сфер. И hard skills очень важны, но и без soft skills совсем никуда (кстати, если вы вдруг собираетесь сменить профессию и\или войти в IT с нуля, если у вас есть хорошие soft skills, то даже при минимальных хардах - вам будет проще. Потому что последним научиться можно и не так уж сложно, а вот взрастить в себе "мягкие" заметно тяжелее, хотя тоже возможно).

И что больше всего меня радует в последние 2-3 года - с нами, как с аналитиками в частности и с командой разработки в целом, наконец научились работать заказчики. Они уже знают, чего хотят, знают как эти хотелки формализовать таким образом, чтобы нам было проще понять и реализовать (некоторые заказчики настолько крутые, что в целом могут и сами ТЗ на раз-два написать). Плюс почти на всех проектах собрались полностью укомплектованные команды со всеми закрытыми позициями. Т.е. теперь системному аналитику не приходится выполнять функцию и бизнес-аналитика и проектировщика, и тестировщика и еще специалиста второй линии поддержки для полного счастья. Есть возможность полностью сконцентрироваться на том, что тебе нравится - для меня это, например, описание технической части, интеграции между системами. Можно даже не общаться с заказчиками, если нет такого желания, так как для этого есть бизнес-аналитик и PO от которых тебе и поступают требования, прошедшие первую стадию формализации.

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

По поводу востребованности - на данный момент ощущается сильная нехватка квалифицированных специалистов, уровня хотя бы middle\middle+ даже среди известных мне проектов. Если говорить по поводу джуниорских или стажерских позиций, то тут ситуация заметно хуже, не буду скрывать, и войти сейчас в разы тяжелее, чем пару лет назад.

Солидную часть в это положение внесли бесконечные (и не всегда очень полезные) курсы, да простят меня geekBrains'ы и иже с ними, которые за последний только год подготовили несколько тысяч начинающих специалистов, а суммарно по всем образовательным площадкам вырисовывается очень большое число людей, которым пообещали работу после курсов и теперь они в поиске. Поэтому на позиции начального уровня конкуренция большая, действительно. Однако! Если хорошо подготовиться, изучить те темы, которые почти нигде не освещаются (в основном это как раз техническая часть, различные виды интеграции), составить качественное резюме и написать сопроводительное письмо - шансы сильно повышаются, доказано на моей практике в том числе.

Вводный пост получился заметно больше, чем я хотел (еще и без картинок) - простите, увлекся. Если кто-то осилил до этого момент - крайне признателен. Еще более признателен буду вопросам по карьере\профессии\чему угодно связанному со сферой IT - постараюсь ответить на всё.

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

P.S. Если заинтересовались - переходите в мой телеграмм-канал , там также делюсь разным про профессию. Если кто-то хочет более хардовой инфы, про интеграцию и прочие сложные штуки - читайте последние посты)

P.P.S: Ну и как принято на пикабу - первый пост, кидайте тапками, подписывайтесь, все дела.

Всем привет.

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

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

REST

Representational State Transfer (REST) в переводе — это передача состояния представления.

Сам по себе REST – это архитектурный стиль взаимодействия компонентов распределённого приложения в сети. Архитектурный стиль – это набор согласованных ограничений и принципов проектирования, позволяющий добиться определённых свойств системы.

И у него есть определенные принципы, которые важно понимать и применять при проектировании системы.

1. Client-Server (клиент-серверная архитектура)

В рамках данного принципа самое важное - это отделение клиента и сервера. Клиент - это интерфейсная часть (уровень представления), сервер - это центральное звено системы, на котором реализованы все основные функции системы (наш backend). Более подробно рассмотрено в части 6 этой серии.

2. Stateless. Без состояния

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

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

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

3. Единообразие интерфейса

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

Это достигается через несколько субограничений:

1. Идентификация ресурсов

В терминологии REST что угодно может быть ресурсом — HTML-документ, изображение, информация о конкретном пользователе - то, чему можно дать имя. Каждый ресурс должен быть уникально обозначен постоянным идентификатором. «Постоянный» означает, что идентификатор не изменится за время обмена данными, и даже когда изменится состояние ресурса. Если ресурсу присваивается другой идентификатор, сервер должен сообщить клиенту, что запрос был неудачным и дать ссылку на новый адрес.

Тут важно понимать, что в REST (в идеале, по крайней мере), ресурс может быть только существительным, а не глаголом. Потому что за "глагол", т.е. действие - отвечает конкретный метод.

2. Управление ресурсами через представления

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

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

3. Самодостаточные сообщения

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

4. Кэширование

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

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

Т.е. стандартный запрос выглядит условно так: Фронт -> микросервис адаптер к фронту -> какой-нибудь микросервис MDM системы пользователей -> база где лежат пользователи и потом обратный путь. Это не прям мгновенно всё происходит. Что мы делаем - например, наш фронт прислал запрос GET /user/121, мы проделали этот путь, описанный выше, но еще и сохранили эти данные в кэше на уровне микросервиса-адаптера. В следующий раз, когда фронт вызовет метод GET /user/121, наш путь будет намного короче и быстрее - всего лишь от фронта к нашему же микросервису в кэш и сразу обратно.

Тут есть множество нюансов, которые нужно учесть - но в целом полезный инструмент.

5. Система слоев

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

Но что самое замечательное, при добавлении новых слоев между клиентом и сервером - их не нужно дорабатывать. Т.е. не важно, если у нас архитектура выглядит как просто "Клиент" -> "Сервер", или "Клиент" -> "Прокси" -> "Балансировщик" -> "Несколько серверов" - их логика не меняется (тут разработчики могут меня поправить или дополнить, буду благодарен).

Что-то вроде того:

Еще есть отдельный принцип "Код по требованию", который подразумевает то, что клиент может получить с сервера прям "кусок кода" (условно), который ему необходимо выполнить у себя.

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

P.S.: В следующих постах расскажу про best practices, связанных с именованием эндпоинтов и прочими полезными штуками для проектирования своих апишек.

По традиции - буду признателен за вопросы про карьеру\профессию\чему угодно связанному со сферой IT - постараюсь ответить на всё.

P.P.S.: Также веду телеграмм-канал, в котором делюсь разным про профессию и про свой путь в ней. Есть и хардовая информация (асинхронные, синхронные интеграции, примеры ТЗ\шаблонов написания микросервисов), так и более софтовая - см. закрепленный дайджест.

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

Еще небольшое предисловие - судя по комментариям к предыдущему посту, не все понимают, что не обязательно, что ВСЕ эти вопросы попадутся вам одновременно. Это наиболее вероятные вопросы, которые вам зададут ( по крайней мере актуально для ФинТех сферы). Ну и опять же, всё очень зависит от интервьюера, его опыта и тех целей, которые ему поставило руководство компании\проекта, на интервью.

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

Более техническая часть собеса:

1. Архитектурно-интеграционные вопросы:

   1. Что такое клиент-серверная архитектура? Что такое тонкий и толстый клиент, чем они отличаются? (Тут никто не ждет прям уверенных технических знаний и деталей реализации того или иного подхода, но в общих чертах знать нужно).

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

   3. Что такое REST? Какие основные принципы у него есть? Какие методы есть в REST? В чем разница между GET и POST запросом?

   4. В каких местах (четырех) мы можем передать атрибуты в запросе? (Path, Body, Query, Header).

   5. Что вы знаете про концепцию CRUD?

   6. Что такое идемпотентность? Какие методы являются идемпотентными?

   7. Что такое синхронные и асинхронные интеграции? В чем между ними разницы? С помощью чего можно их реализовать?

   8. Можно ли реализовать асинхронную интеграцию через REST? (Вряд ли этот вопрос будут задавать, если вы не ответите на предыдущие. Это скорее со звездочкой и не обязательный)

   9. Что такое очередь сообщений? Как передаются сообщения через очередь? Какие очереди сообщений есть и в чем между ними разница? (Если расскажете про PUSH/PULL-стратегии - плюсик в карму обеспечен)

   10. Что такое гарантированная доставка сообщений и какими механизмами ее можно обеспечить?

   11. Какие вообще способы интеграции существуют? С какими из них приходилось работать? В чем их преимущества и недостатки? (Интеграция через обмен файлами, через общую БД, через веб-сервисы и обмен сообщениями)

2. Базы данных:

   1. Что такое базы данных? Какими они бывают? С каким БД приходилось работать?

   2. Что такое ER-диаграммы? Приходилось ли их проектировать?

   3. На какой уровень оцениваете свой уровень владения SQL? С какими инструментами по работе с БД знакомы?

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

3. Различные задачки:

   1. Тут вообще кто во что горазд в плане придумывания задач. В среднем, вам дадут умозрительное задание на проектирование какой-либо системы и попросят выделить основные классы этой системы (возможно, предварительно нужно будет собрать требования с интервьюера), спроектировать интеграцию между частями этой системы/интеграцию с внешними системами (плюс объяснить выбор технологии интеграции). Основной упор на ваши размышления, в основном именно в подобных вопросах можно понять уровень соискателя, потому что все остальные можно заучить. А тут проверяется именно понимание того, о чем вы рассказывали предыдущую часть собеседования.

4. Небольшие оффтопные вопросы:

   1. Расскажите, что такое авторизация, аутентификация и идентификация? Чем они отличаются друг от друга? (почему-то один из самых любимых вопросов некоторых людей)

   2. Чем верификация отличается от валидации?

   3. Приходилось ли работать с JIRA\Confluence?

Конечно, так получается, что если вы знаете ответы на все эти вопросы, или больше 80-90%, то как будто бы вы уже не джун. Но чем лучше вы отвечаете, чем лучше вы соответственно подготовились - тем больше вам зададут вопросов (в нормальном интервью, а не шаблонном). Что очень сильно повысит ваши шансы получить оффер и выделиться среди других кандидатов.

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

P.S.: По традиции - буду признателен за вопросы про карьеру\профессию\чему угодно связанному со сферой IT - постараюсь ответить на всё.

P.P.S.: Также веду телеграмм-канал, в котором делюсь разным про профессию и про свой путь в ней. Есть огромное количество постов на тему софт-,хард-скиллов и про карьеру в целом - см. закрепленный дайджест.

❕Сегодня хочу поговорить на очень спорную тему, я бы даже сказал философскую. Отчасти из-за нее, возникает очень много непонимания между коллегами, работающими в одном и том же (казалось бы) "АйТи", но почему-то имеющих очень разное представление о процессах разработки и о том, что каждая роль команды должна выполнять. Особенно это часто всплывает в моих постах на этом ресурсе, в комментариях - это такой хороший срез из разных уголков нашего отечественного IT.

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

Давайте поговорим о том, какие есть подходы к написанию ТЗ и степени его проработки на примере описания тех же микросервисов\их методов.

❕Представим, что мы является системным аналитиком в команде и нам поставили задачу - реализовать личный кабинет пользователя.

Т.е. когда пользователь нажимает на какую-нибудь иконку профиля в приложении или там на кнопку "Профиль" - ему должна открываться экранная форма, в которой ему отрисовывается определенный набор полей и эти поля заполняются информацией. Также допустим, что у нас сам объект "Пользователь" уже есть в системе, атрибутивный состав понятен и нужно только реализовать процесс получения данных о пользователе на фронт по его идентификатору (ТЗ на фронт, на экранную форму и на интеграцию его с бэком опустим).

Какие есть варианты написания ТЗ для данной задачи?

1️⃣Самый минимальный уровень детализации. Это когда системный аналитик просто ставит задачу на разработку Джире (ну или в рамках небольшой страничке в конфлю\ворде, в зависимости от того, как принято) и в постановке этой задачи пишет что-то вроде "Требуется реализовать процесс получения данных о пользователе и передачу ее с бэка на фронт по REST-запросу. Со стороны фронта требуется создать новую экранную форму приложения - "Личный кабинет" или "Профиль пользователя". Со стороны бэка требуется реализовать новый метод, который будет использовать фронт для запроса информацию по пользователю (и, скорее всего, перечисляет набор полей, которые должны передаваться на фронт в формате "Фамилия", "Имя" и т.д.)". Усё

Я не утрирую - это один из вариантов реального "ТЗ" на эту задачу. Плюсом к этому может быть описан пользовательский сценарий в вольном формате или в формате UC (и то это будет в лучшем случае). Т.е. по сути в рамках такого процесса разработчик получает из полезной информации - только состав полей, передачу которых ему нужно реализовать по запросу с фронта, и то только их наименования.

2️⃣Вариант с немного лучшей детализацией. В этом формате системный аналитик уже пишет ТЗ в каком-либо формате, в рамках которого указывает, что: "Требуется реализовать новый метод GET /users/, указывает полноценно параметры, которые данный метод должен потреблять на вход и параметры, которые он должен отдавать на выходе." Плюс может описать, также как в предыдущем пункте, верхнеуровневый сценарий взаимодействия с этим методом.

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

3️⃣Вариант с достойной реализацией. Этот вариант обычно используется на большинстве проектов ФинТеховских и я считаю его достаточным для того, чтобы написать хорошее, качественное ТЗ и разгрузить разработчика так, чтобы он не думал о деталях реализации, хотя бы алгоритмических и системных (то, к чему нужно стремиться со стороны СА, имхо).

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

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

4️⃣Более полноценный вариант придумать не могу =)

Плюсом к 3 пункту дополнительно описывается еще и swagger-спецификация микросервиса в целом и конкретных эндпоинтов в частности. Кроме того, что это просто удобно, наглядно и очень детально - эту спецификацию разработчики могут использовать, чтобы сконвертировать ее напрямую в готовый код с расписанными классами и эндпоинтами, останется "только" докрутить бизнес-логику и метод готов (Тут просьба поправить меня коллегам, которые более глубоко погружены в разработку - так ли это или есть еще какие-то бенефиты для разработчиков. Могу в этом предложении быть не прав, пишу исходя из того, как мне это объясняли).

Кроме этого, такой подход хорошо использовать в парадигме swagger-first, особенно когда у вас есть насыщенный и активный процесс кросс-командной разработки. Отдать другой команде сваггер аналитику куда проще и быстрее, чем отдать полноценное ТЗ на сервис - хотя бы просто по времени. А большего им и не нужно (потому что им пофиг на то, как работает ваш сервис внутри, главное понять, как вас вызывать и что вы вернете в ответе).

А если это все еще и использовать в связке с asciidoc-документацией, выкладывании ее в git- ммм, сказка просто. Как вспоминаю об этих процессах, наворачивается скупая слеза ностальгии - как же это было здорово! Жаль, что я встретил это ровно в одном проекте, а во всех последующих так и не смог продавить внедрение чего-то похожего.

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

А с какими процессами и подходами работаете вы?

P.S.: По традиции - буду признателен за вопросы про карьеру\профессию\чему угодно связанному со сферой IT - постараюсь ответить на всё.

P.P.S.: Также веду телеграмм-канал, в котором делюсь разным про профессию и про свой путь в ней. Есть огромное количество постов на тему софт-, хард-скиллов и про карьеру в целом - см. закрепленный дайджест.

Стоило только добавить волну профессий и титьки в игнор на неделю и вот результат 10 минут в горячем на Пикабу.
Грусть печаль(((