Вчера замерз дома и решил утеплиться. И надел старую рубашку. Теплую фланелевую рубашку. Рубашку деда. Бабушка отдала мне ее, когда деда не стало. Это было 22 года назад.
Помню, как не носил и не стирал ее несколько лет, потому что она пахла им. Пахла им, одеколоном, машинным маслом и мятой. Он очень любил чай с мятой. Помню, как доставал эту рубашку из шкафа и просто нюхал. Этот запах напоминал о нем и пытался обмануть мозг, давая ощущение, что дед все еще жив. Потом я убирал рубашку обратно, моля всех богов мира, чтобы запах не выветрился.
Тогда мне его очень не хватало.
У меня не было отца. Зато был дед. Нет, не так. Был Дед.
Самое яркое воспоминание о дедушке – это его руки. Кисти рук. Большие и почти бронзовые от въевшегося в кожу загара. Одна его ладонь – это две моих. Хотя, гигантом он не был.
Когда мне сообщили, что дед умер, первая картинка, которая появилась в моей голове – это дед, лежащий в поле среди цветов. Не знаю, как и почему она возникла перед глазами, но, когда я приехал на похороны, я узнал, что дед умер в поле, и нашли его лежащим среди полевых цветов.
Он умер, когда мне было 17. Он не увидел, как я закончил школу, как закончил институт, как пришел из армии, как женился и как стал отцом. Уверен, он бы очень радовался правнуку, точно так же, как радовался мне.
Он всегда улыбался, глядя на меня. Он видел во мне не внука, а сына, ведь своих сыновей у него не было, были только дочки. А он всегда хотел парня.
Помню, как он учил меня (как в фильме «Любовь и голуби») ползать по пластунски, как мы искали в переставшей моргать гирлянде перегоревшую лампочку, как чинили крыльцо, и как несли ночное дежурство на огороде, когда рядом с нашей деревней несколько дней стоял цыганский табор. Это были одни из лучших моментов детства.
Дед научил меня всему – починить кран, прибить полку, прочистить карбюратор. У него был заветный чемоданчик, в котором лежала волшебная синяя изолента, кусачки, молоток, мотки проволоки и еще куча всякого нужного и не очень инструмента. И когда мне разрешалось прикоснуться к этому ларцу сокровищ, я был на седьмом небе от счастья.
Помню, как мы ставили с ним забор в деревне. Мне было лет семь, и он дал задание укрепить уже приколоченные им жерди к столбам. Понятно, что укреплять их не было никакого смысла, но дед сказал, что моя помощь ему просто необходима, вручил мне молоток и гвозди, показал, как и куда нужно колотить.
Я обколотил гвоздями всё. И жерди, и столбы, и калитку. Наверно, такой бессмысленной траты гвоздей свет еще не видывал. Гвозди были абсолютно везде. Помню, бабушка ворчала, что я перевел столько гвоздей понапрасну, а дед только ухмылялся – пускай учится! А я был неимоверно горд собой, на сто процентов уверенный в том, что без меня забор при первом же ветре бы развалился.
Помню его трактор, огромный тракторище, на котором он работал.
Примерно вот такой.
Помню, малым, всегда ждал его приезда на обед, чтобы, пока он кушает, посидеть в таком красавце.
Одно из самых ярких воспоминаний – рассказ деда о том, как он в детстве грел ноги, когда пас коров. Обуви не было, и чтобы ноги не мерзли, он просто вставал босыми ногами в свежую коровью лепешку и стоял в ней, пока она не остывала. А когда она остывала, он искал другую, потеплее.
Наверное, поэтому, он всегда очень бережно относился к обуви. Он даже ходил так, что его обувь всегда оставалась чистой и в дождь и слякоть. Помню, как бабушка постоянно удивлялась тому, что идя вдвоем с ним по одной и той же дороге, он всегда оставался чистым, а ее обувь и ноги – забрызганными чуть не до колена.
А еще он никогда не матерился. Нет, может быть, на заводе он и отпускал крепкие словечки, но при родных и знакомых самое ругательное слово от него было слово «собака».
Не заводится запорожец – собака!
Ударился о косяк в бане – собака! (сколько помню – он всегда бился затылком об этот чертов косяк)
Сорока утащила яйцо из курятника – собака!!!
Ах, да – дед очень любил своих кур. Даже давал каждой имя. Из всей семьи только мне было разрешено тоже участвовать в раздавании имен. Помню, была одна курица, которая перестала нестись, пытаясь высидеть птенца. Как говорили у нас в деревне – запарИла (типа, сидеть на яйце – парить). Я, будучи еще мальцом, недолго думая предложил назвать эту курицу Парнушкой. Ну, она же запарила. Похихикав, взрослые отклонили мое предложение. А я еще долго дулся, не понимая почему.
А еще дед никогда меня не ругал. Нет, у него нельзя было забаловать – он был строг, но справедлив. Однажды я запер его в бане (случайно), и он просидел там несколько часов (не хотел ломать дверь), пока мы ходили с бабушкой в соседнюю деревню. И мне за это ничего не было, только укоризненный взгляд. А вот если бы я запер бабушку, то получил бы по жопе. Хотя, бабушка у меня тоже золотая. Про нее расскажу в другой раз.
А дед … Благодаря деду у меня был отец!
Всем добра!
Мозг в стрессовой ситуации ведёт себя порой не совсем адекватно.
Была у меня одна история, как раз про такой случай.
Дабы не смущать героев сего случая, постараюсь место действия и имена не афишировать.
Есть у нас традиция - по весне после копа заскакивать на пару дней в один прекрасный город-герой на Волге.
Вот и в этот раз сняли мы на троих квартирку, закупились пивом в ближайшем магазине, и с полными пакетами брели к месту временной дислокации.
Вдруг в животе у нашего товарища, судя по звуку, произошла революция, видимо, съеденный на вокзале чебурек решил сместить действующую власть и устроил вооружённый конфликт.
Товарищ понял, что может не успеть, отдаёт нам пакеты и устремляется в сторону квартирки. Ооо, как он бежал, Усейн Болт нервно курит в сторонке и утирает скупую мужскую слезу.
-Вась, ключи-то нам оставь, - метров через сто его остановил окрик другого моего товарища.
Василий разворачивается с тем самым словом, которое каждый из нас произносит, попадая себе молотком по пальцу, добегает обратно до нас, передаёт ключи от квартиры и упуливает обратно.
-Ты зачем у него ключи забрал? - спрашиваю я.
-А как мы в квартиру попадём?
-А он как?
-Кто?
-ВАСЯ.
Друг жмёт плечами, и мы продолжаем свой неспешный путь.
Васю и всё, что он о нас думает, мы услышали ещё на подходе к подъезду.
Он, или скорее мы, успели, но каких неимоверных сил это стоило нашему страдающему товарищу, никто не знает.
Было это довольно давно, но недостаточно, чтобы вся боль утраты прошла бесследно, а жизнь вымарала из памяти этот случай.
Как-то по осени поехали мы веселой командой копнуть один немецкий офицерский блиндаж в надежде добыть что-нибудь ценное или хотя бы интересное, так как весь прошедший сезон нам не везло, и прошел он, можно сказать, вхолостую.
Искомое место встретило нас осенней сыростью и нудным дождём. Копать пришлось долго, мокро и до одури много.
А что самое обидное - впустую. Печка и разный железный бытовой хлам наподобие скоб и пары котелков не в счёт.
И вот, уже почти отчаявшись, в дальнем углу камрад натыкается на какой-то ящик. Вскрываем и находим на дне четыре зеленых пузатых бутылки с сургучными печатями на боку.
Коньяк.
День уже перевалил к вечеру, уставшие и мокрые, решаем ночевать на месте.
И вот у походного костра поступает предложение - одну пробуем, три оставляем, и дома думаем, что с ними делать.
Тогда никто не задумывался на предмет цены находки и возможности отравления.
Предложение было воспринято на ура, точнее, по итогу, на все четыре бутылки. Коньяк особенно хорошо пошел под гречку с тушенкой из армейского сухпайка, сваренной на костре и разложенной по алюминиевым котелкам.
И только спустя несколько дней мне позвонил товарищ, который учавствовал в дегустации, и сказал, что это была самая дорогая лесная попойка, которую видели окрестные земли. Цену за бутылочку он мне так и не сказал, дабы не травмировать до конца мою психику, но думаю, гульнули мы знатно, с шиком, не хватало только цыган с медведем и стрельбы по бутылкам из пистолета.Достойное завершение провального сезона.
Бывает так, "застрянет" какая-то мысль или образ в голове и никак от нее не отвязаться
Я сейчас нахожусь в блокадном Калининграде. Ем копченого угря, запиваю Крушовице. Жду с нетерпением, когда на Балтике установится лед, откроется дорога жизни и начнут подвозить тёмное. А то осталось только светлое, а я его не очень.
Два дня назад в стамбульском аэропорту, в дьютике. Кассир - молодой турок лет 25, не больше. Даю ему паспорт и билет, чтобы купить то, что хотел. Он скривился, глядя на паспорт, говорит мне на английском: -Плохо быть русским? (явно имея в виду ситуацию в мире).
Я сделал скорбное лицо и ему, тоже на английском: - Прими мои соболезнования по поводу землетрясения. Потом по-русски ему :-Пошел на хуй.
Явно было видно, что он понял. Сука.
Сейчас ещё раз подтвердилось это выражение. Иду по улице и вижу на дороге мёртвую маленькую птичку. С виду без повреждений, т.е. не раздавлена и кошаками не задрана, целенькая, но мёртвая. Я тормознула возле неё буквально на пару секунд и пошла дальше. Иду вдоль длинного здания, вдруг с крыши срывается кусок льда, падает перед моим носом и вдребезги разбивается под ногами. Не задержись я у птички на лишние пару секунд, я пришла бы на это место чуть раньше, и кусок льда свалился бы аккурат мне на голову. Мёртвая птичка спасла меня от травмы. Спасибо ей.
З.Ы. Фото птички сделала на обратном пути.
Нужно ли учитывать калорийность алкоголя? Если да, означает ли это, что он может откладываться в жир? Можно ли набухать себе пузяку? Знаменитое «пивное пиво» - миф или повод для гордости? Давайте разбираться.
На 1 г белков и углеводов приходится 4 ккал (на самом деле, 4,1 ккал), на 1 г жиров – 9 ккал (на самом деле, 9,3 ккал), а на 1 г спирта приходится 7 ккал, что тоже довольно много. Например, на 100 г водки приходится примерно 235 ккал. При этом 0 белков, 0 жиров, и ничтожное количество углеводов. Именно поэтому калории из водяры принято считать «пустыми», ибо калории есть, а питательных веществ, по сути, нет.
В одном исследовании людям определили их норму калорий, но в одном случае к этой норме добавили 25% этанола, в другом, сохраняя общую норму калорий, 25% доли жиров и углеводов было заменено на этанол [1]. В любом случае добавления этанола, окисление жиров было снижено, хотя существенно не повлияло на окисление белков и углеводов. При этом этанол УВЕЛИЧИЛ затратную часть энергии. «Привычное потребление этанола сверх энергетических потребностей, вероятно, способствует накоплению липидов и увеличению веса».
Короче говоря, калорийность алкоголя учитывать обязательно нужно. Кроме того, никто ж не пьёт этанол. Вино, ликёр, коктейли и прочие напитки, содержащие приличную долю сахаров. Поступая в организм, этанол становится первостепенным источником энергии, ибо организм старается избавиться от этого «отравления».
Около 50% энергии алкашки идёт на окисление этой самой алкашки [2, 3]. Различные затраты на утилизацию спирта печенью (около 20%) и прочее [4].
Таким образом, сам по себе этанол в жир на жопе не откладывается, но он мешает окислению собственных жиров. Условно говоря, поступающие калории из еды будут «откладываться», пока организм не выведет эту пакость. И чем больше вы пьёте, тем больше ресурсов организм подключает на расщепление спирта, как бы «ускоряя метаболизм» [5].
Поэтому если вы укладываете калорийность алкоголя в свою норму, то терпимо, а если вы «напили» сверх вашей нормы, несмотря на то, что вы «недоели» норму, всё может «отложиться».
Выводы:
- сам по себе этанол в жир не отложится, но помешает окислению собственных жиров;
- учитывать калорийность алкоголя НУЖНО, тем более что множество алкогольных напитков содержат большое количество сахара;
- попадая в организм, этанол становится первостепенным источником энергии, от которого организм всячески стремится избавиться, а поступаемся пища может «отложиться»;
- сюда добавляем тот факт, что «под алкашку» человек, как правило, закусывает сверх всякой нормы, что, потенциально, делает алкоголь ещё опаснее в этом плане (это что касается «пивного пуза» - люди жрут как не в себя, а виновато пиво);
- ну и не забываем, что любой алкоголь – это зло! Избавьтесь от него поскорее!
Всем добра!
Исследователь по ИБ Хьюго Ландау рассказ, как взломать дверь с электроприводом в санузел на поезде Intercity Express в Великобритании.
Сам туалет состоит из следующих элементов элементов:
1) две кнопки, служат для открытия и закрытия двери.
2) рычаг, нужен для переключения блокировки/разблокировки двери. Сзади него есть отверстия для штыря, который блокирует ручку
3) крошечный штифт
4) микроконтроллер
Проблема в том что, микроконтроллер не точно считывает положение рычага. То есть если при повороте с закрытого положения задержать ручку посередине (замок заблокирован), то мк считывает открытое положение и выпускает штифт (дверь откроется, но замок заблокирован). Штырь зафиксирует ручку, а кнопка закрытия будет активна.
Тогда можно выйти из туалета и по кнопки закрыть дверь с активным замком. Все, туалет больше не доступен.
#без_пяти_минут_как_актуально
30 января пользователи стали сообщать о недоступности сайтов и сервисов крупных банков, маркетплейсов и других популярных российских онлайн-служб, включая «Яндекс» и «ВКонтакте». Проблему обнаружили около 18:30 по московскому времени
По сообщениям, причиной этих сбоев стала авария, связанная с DNSSEC. Временным решением проблемы стало подключение к сервисам по IP-адресу. Сбой затронул сервисы различных интернет-провайдеров РФ, так как цифровые подписи доменов в зоне RU оказались нарушены.
DNSSEC — это протокол для повышения безопасности системы доменных имен (DNS). Смысл DNS в том, что каждому цифровому IP-адресу присваивается понятное буквенное имя .Когда вы вводите в браузере доменное имя, сервера DNS автоматически преобразуют его в IP-адрес (набор цифр). Это происходит за миллисекунды.
Так вот, DNSSEC — это набор расширений протокола DNS, благодаря которому гарантируется целостность и достоверность данных. Благодаря DNSSEC в доменной зоне RU гарантируется исключение вероятности подмены IP-адреса в результате атак.
Представители "МегаФона", "Билайна" и Tele2 подтвердили фиксацию снижения трафика и связали появившуюся проблему не с техническими неполадками на своей стороне. Координационный центр доменов .RU/.РФ также подтвердил наличие проблемы, связанной с "глобальной инфраструктурой DNSSEC".
Жалобы на сбой в Рунете поступали с разных территорий, от Москвы до Дальнего Востока.
Примерно в 22:20 (мск) в Координационном центре доменов .RU/.РФ сообщили, что техническая проблема устранена. Однако ряд пользователей испытывали проблемы еще около полутора часов после этого заявления.
Google объявила о ребрендинге своего ИИ-бота Bard, который теперь официально называется Gemini. На основе этого бота создали Android-приложение с аналогичным названием- Gemini, позволяющие ознакомится с функционалом ии. После установки на устройство с OS Android ИИ-бот Gemini заменяет голосового ассистента Google.
Но придется расстроить яблоководов, ведь приложение не доступно для iOS. Вероятно, из-за того, что пользователи iPhone всё равно не могли бы задействовать бота Google в качестве помощника по умолчанию. Однако владельцы устройств Apple могут получить доступ ко всем ИИ-функциям в приложении Google.
Стоит напомнить, что ранние концепты Gemini представили еще в декабре 2023. Уже тогда заявлялось, что Gemini передовой мультимодальный искусственный интеллект Google, созданый в результате совместных усилий объединенных лабораторий DeepMind и Brain AI, который стоит на плечах своих предшественников, обещая предоставить более взаимосвязанный и интеллектуальный набор приложений.
Сама же модель Gemini способна обрабатывать различные типы данных, такие как текст, изображения, аудио и видео. Он поставляется в трех версиях : Ultra превосходно справляется с многогранными задачами и будет доступен в Bard Advanced Pro предлагает баланс производительности и эффективности использования ресурсов, уже интегрированный в Bard для текстовых подсказок. Nano, оптимизированный для развертывания на устройстве, доступен в двух размерах и оснащен аппаратной оптимизацией, такой как 4-битное квантование, для автономного использования на таких устройствах, как Pixel 8 Pro.
В основе бесплатной общедоступной версии ИИ-бота лежит большая языковая модель Gemini Pro. Чтобы получить доступ к самой мощной языковой модели Google Gemini Ultra, придётся оформить подписку Gemini Advanced, которая входит в пакет Google One AI Premium стоимостью $20 в месяц. Подписка также включает в себя 2 Тбайт облачного хранилища и другие возможности
Делегирование — это не спихивание своих задач на других людей, а передача части функций, когда ответственность за результаты остаётся на делегирующем. А иногда вместе с задачей передаётся и часть полномочий. В этом случае на плечи другого человека ложится ещё и ответственность за результаты.
Это и морально, и по части реализации непростой процесс — надо понять, насколько ты как менеджер чувствуешь готовность передать дела другому человеку, и предварительно убедить себя и сотрудника, что дело будет выполнено.
В процессе передачи задачек другому человеку тебе пригодится чек-лист по делегированию из книги Джоаны Ротман и Эстер Дерби (Johanna Rothman and Esther Derby) «Behind Closed Doors. Secrets of Great Management» (на русский не переводилась).
Авторы сделали короткий чек-лист для самопроверки перед делегированием задач.
? Я учитываю все факторы риска при делегировании этой задачи?
? Выбранный сотрудник(и) сумеет распорядиться возложенными полномочиями?
? Продумано, кому будет делегировано дело: отдельному сотруднику или команде/группе сотрудников?
? Хорошо продуман выбор уровня полномочий, который нужен для решения этой задачи? .
? Решено ли, насколько большой пласт работы я собираюсь делегировать?
? У получателя задачи достаточно навыков для выполнения этой работы?
? Созданы все организационные условия для выполнения этой задачи?
? У сотрудника есть все инструменты для выполнения этой задачи?
? Ясно, каким должен быть конечный результат?
? Ясно, каким должен быть результат промежуточных этапов?
? Установлены необходимые ограничения — бюджет, доступные ресурсы, в том числе человеческие, качество?
? Для выполнения задачи установлен чёткий дедлайн?
? Оговорено, как часто и в какой форме я буду получать информацию о ходе выполнения работы и промежуточных этапов?
? Если понадобится помощь — понятно, к кому обратиться, чтобы получить её?
На каждый пункт надо отвечать «Да», «Нет» или «Неприменимо». И даже ответ «Нет» на какой-то из пунктов не означает, что делегировать не получится. Просто открыто проговори этот момент с сотрудником (или группой сотрудников), кто получает задачу, — желательно до принятия решения или достижения компромисса. Главное, не дать потенциальной проблеме перерасти в настоящую.
Всем привет.
Сегодня перейдем к более прикладной и конкретной теории, без которой нельзя обойтись хоть бизнес-, хоть системному аналитику (к слову, один из самых частых вопросов, который задают на собеседовании начинающего аналитика - какие виды требований ты знаешь? Какими качествами требование должно обладать?).
Не буду душнить и писать сухую теорию про то, что требование - это совокупность утверждений относительно атрибутов, свойств или качеств программной системы... бла-бла-бла. Я думаю, что все понимают - что такое требование к системе. Теперь давайте разберемся, какими они бывают.
Общепринято делить требования на следующие категории:
Функциональные требования, которые включают в себя:
Бизнес-требования - что система должна делать с точки зрения бизнеса. Т.е. содержат в себе высокоуровневые задачи и цели заказчика. Как правило их формулируют именно те люди, которые заказывают какой-либо продукт. Они описывают те цели, которые заказчик намеревается достичь с помощью системы (ПО). В 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 – это архитектурный стиль взаимодействия компонентов распределённого приложения в сети. Архитектурный стиль – это набор согласованных ограничений и принципов проектирования, позволяющий добиться определённых свойств системы.
И у него есть определенные принципы, которые важно понимать и применять при проектировании системы.
В рамках данного принципа самое важное - это отделение клиента и сервера. Клиент - это интерфейсная часть (уровень представления), сервер - это центральное звено системы, на котором реализованы все основные функции системы (наш backend). Более подробно рассмотрено в части 6 этой серии.
Это понятие означает, что сервер не должен хранить информацию о состоянии клиента, в том числе информацию о предыдущих запросах клиента, а клиент не должен знать ничего о текущем состоянии сервера.
Это не значит, что у них вообще нет состояния, но они не отслеживают состояние друг друга (что очень удобно, т.к. избавляет нас от необходимости держать постоянное неразрывное соединение между двумя системами).
Поэтому каждый запрос рассматривается индивидуально, как будто бы не было ничего до, и не будет после. Соответственно клиент в этом случае, обязан предоставить все необходимые данные для успешного выполнения запроса. Это, пожалуй, почти единственная логика, которая должна быть на клиенте.
Принцип гарантирует, что между клиентом и сервером существует общий язык (интерфейс), с помощью которого они будут понимать друг друга. Т.е. клиент посылает понятные серверу запросы, использую конкретные HTTP-методы, сервер посылает ответ в понятном клиенту формате.
Это достигается через несколько субограничений:
Идентификация ресурсов
В терминологии REST что угодно может быть ресурсом — HTML-документ, изображение, информация о конкретном пользователе - то, чему можно дать имя. Каждый ресурс должен быть уникально обозначен постоянным идентификатором. «Постоянный» означает, что идентификатор не изменится за время обмена данными, и даже когда изменится состояние ресурса. Если ресурсу присваивается другой идентификатор, сервер должен сообщить клиенту, что запрос был неудачным и дать ссылку на новый адрес.
Тут важно понимать, что в REST (в идеале, по крайней мере), ресурс может быть только существительным, а не глаголом. Потому что за "глагол", т.е. действие - отвечает конкретный метод.
2. Управление ресурсами через представления
Второе субограничение «унифицированного интерфейса» говорит, что клиент управляет ресурсами, направляя серверу представления, обычно в виде JSON-объекта, содержащего контент, который он хотел бы добавить, удалить или изменить. В REST у сервера полный контроль над ресурсами, и он отвечает за любые изменения.
Когда клиент хочет внести изменения в ресурсы, он посылает серверу представление того, каким он видит итоговый ресурс (а для этого, сервер сначала должен предоставить эту информацию клиенту). Сервер принимает запрос как предложение, но за ним всё так же остаётся полный контроль.
3. Самодостаточные сообщения
Самодостаточные сообщения — это ещё одно ограничение, которое гарантирует унифицированность интерфейса у клиентов и серверов. Только самодостаточное сообщение содержит всю информацию, которая необходима для понимания его получателем. В отдельной документации или другом сообщении не должно быть дополнительной информации.
В данных запроса должно быть указано, нужно ли кэшировать данные (сохранять в специальном буфере для частых запросов). Если такое указание есть, клиент получит право обращаться к этому буферу при необходимости.
Это нужно для того, что максимально ускорить обработку запроса от клиента. Для примера, если нам нужно часто получать информацию о пользователе (а сама информация о пользователе меняется достаточно редко, что важно), то мы можем закэшировать эту информацию.
Т.е. стандартный запрос выглядит условно так: Фронт -> микросервис адаптер к фронту -> какой-нибудь микросервис MDM системы пользователей -> база где лежат пользователи и потом обратный путь. Это не прям мгновенно всё происходит. Что мы делаем - например, наш фронт прислал запрос GET /user/121, мы проделали этот путь, описанный выше, но еще и сохранили эти данные в кэше на уровне микросервиса-адаптера. В следующий раз, когда фронт вызовет метод GET /user/121, наш путь будет намного короче и быстрее - всего лишь от фронта к нашему же микросервису в кэш и сразу обратно.
Тут есть множество нюансов, которые нужно учесть - но в целом полезный инструмент.
Система слоев предполагает наличие большего количества компонентов, чем клиент и сервер. В системе может быть больше одного слоя. Тем не менее, каждый компонент ограничен способностью видеть только соседний слой и взаимодействовать только с ним.
Но что самое замечательное, при добавлении новых слоев между клиентом и сервером - их не нужно дорабатывать. Т.е. не важно, если у нас архитектура выглядит как просто "Клиент" -> "Сервер", или "Клиент" -> "Прокси" -> "Балансировщик" -> "Несколько серверов" - их логика не меняется (тут разработчики могут меня поправить или дополнить, буду благодарен).
Что-то вроде того:
Еще есть отдельный принцип "Код по требованию", который подразумевает то, что клиент может получить с сервера прям "кусок кода" (условно), который ему необходимо выполнить у себя.
Звучит интересно, но честно, ни разу не сталкивался, поэтому не могу что-то детальное рассказать.
P.S.: В следующих постах расскажу про best practices, связанных с именованием эндпоинтов и прочими полезными штуками для проектирования своих апишек.
По традиции - буду признателен за вопросы про карьеру\профессию\чему угодно связанному со сферой IT - постараюсь ответить на всё.
P.P.S.: Также веду телеграмм-канал, в котором делюсь разным про профессию и про свой путь в ней. Есть и хардовая информация (асинхронные, синхронные интеграции, примеры ТЗ\шаблонов написания микросервисов), так и более софтовая - см. закрепленный дайджест.
Продолжаем список тем и вопросов, ответы на которые нужно знать, чтобы пройти собеседование на позицию джуниора.
Еще небольшое предисловие - судя по комментариям к предыдущему посту, не все понимают, что не обязательно, что ВСЕ эти вопросы попадутся вам одновременно. Это наиболее вероятные вопросы, которые вам зададут ( по крайней мере актуально для ФинТех сферы). Ну и опять же, всё очень зависит от интервьюера, его опыта и тех целей, которые ему поставило руководство компании\проекта, на интервью.
Есть еще очень хороший подход к интервью, когда ты задаешь вопросы по каждой теме, и чем больше правильных ответов дает соискатель - тем глубже ты копаешь в эту тему, пока его знания по вопросу не иссякнут. Это позволяет не просто прогнать человека по заданным темам, которые нужны компании, но и в целом представить его уровень более детально (плюс так куда интересней для всех участников собеса).
Более техническая часть собеса:
Архитектурно-интеграционные вопросы:
Что такое клиент-серверная архитектура? Что такое тонкий и толстый клиент, чем они отличаются? (Тут никто не ждет прям уверенных технических знаний и деталей реализации того или иного подхода, но в общих чертах знать нужно).
Что такое HTTP? Какие основные методы HTTP вы знаете? Какие функции они выполняют? Расскажите про структуру HTTP-сообщений. (Если вы перечислите основные методы и скажете, что у сообщения есть заголовок, строка и тело - это уже, в целом, неплохо. Если знаете больше этого, вообще замечательно).
Что такое REST? Какие основные принципы у него есть? Какие методы есть в REST? В чем разница между GET и POST запросом?
В каких местах (четырех) мы можем передать атрибуты в запросе? (Path, Body, Query, Header).
Что вы знаете про концепцию CRUD?
Что такое идемпотентность? Какие методы являются идемпотентными?
Что такое синхронные и асинхронные интеграции? В чем между ними разницы? С помощью чего можно их реализовать?
Можно ли реализовать асинхронную интеграцию через REST? (Вряд ли этот вопрос будут задавать, если вы не ответите на предыдущие. Это скорее со звездочкой и не обязательный)
Что такое очередь сообщений? Как передаются сообщения через очередь? Какие очереди сообщений есть и в чем между ними разница? (Если расскажете про PUSH/PULL-стратегии - плюсик в карму обеспечен)
Что такое гарантированная доставка сообщений и какими механизмами ее можно обеспечить?
Какие вообще способы интеграции существуют? С какими из них приходилось работать? В чем их преимущества и недостатки? (Интеграция через обмен файлами, через общую БД, через веб-сервисы и обмен сообщениями)
Базы данных:
Что такое базы данных? Какими они бывают? С каким БД приходилось работать?
Что такое ER-диаграммы? Приходилось ли их проектировать?
На какой уровень оцениваете свой уровень владения SQL? С какими инструментами по работе с БД знакомы?
Ну тут могут конечно и про формы нормализации спросить, но уже лишнее, как по мне. Я обычно спрашиваю больше про опыт проектирования БД в целом. Приходилось ли проектировать базу в целом и под конкретные задачи в частности, каким образом это было сделано.
Различные задачки:
Тут вообще кто во что горазд в плане придумывания задач. В среднем, вам дадут умозрительное задание на проектирование какой-либо системы и попросят выделить основные классы этой системы (возможно, предварительно нужно будет собрать требования с интервьюера), спроектировать интеграцию между частями этой системы/интеграцию с внешними системами (плюс объяснить выбор технологии интеграции). Основной упор на ваши размышления, в основном именно в подобных вопросах можно понять уровень соискателя, потому что все остальные можно заучить. А тут проверяется именно понимание того, о чем вы рассказывали предыдущую часть собеседования.
Небольшие оффтопные вопросы:
Расскажите, что такое авторизация, аутентификация и идентификация? Чем они отличаются друг от друга? (почему-то один из самых любимых вопросов некоторых людей)
Чем верификация отличается от валидации?
Приходилось ли работать с JIRA\Confluence?
Конечно, так получается, что если вы знаете ответы на все эти вопросы, или больше 80-90%, то как будто бы вы уже не джун. Но чем лучше вы отвечаете, чем лучше вы соответственно подготовились - тем больше вам зададут вопросов (в нормальном интервью, а не шаблонном). Что очень сильно повысит ваши шансы получить оффер и выделиться среди других кандидатов.
Поэтому, конечно, можно, и зачастую нужно, пробовать собеседоваться, при наличии знаний, которые позволят ответить вам на половину из этих вопросов - шансы всё еще будут, плюс вы получите опыт прохождения собеседований (что само по себе очень важно) и определите те темы, про которые часто спрашивают, но в которых вы пока еще не сильны.
P.S.: По традиции - буду признателен за вопросы про карьеру\профессию\чему угодно связанному со сферой IT - постараюсь ответить на всё.
P.P.S.: Также веду телеграмм-канал, в котором делюсь разным про профессию и про свой путь в ней. Есть огромное количество постов на тему софт-,хард-скиллов и про карьеру в целом - см. закрепленный дайджест.
