В конце технического интервью, если кандидат ответил на вопросы и справился с задачами, у нас есть время для свободных вопросов, которые можно задать команде или кому-то из интервьюеров. Эту практику я переносил из компании в компанию, и она всегда помогала разрядить обстановку или вывести человека на разговор, если он был напряжен во время общения. Вопросы могут быть любые, кроме личных или тех, что под NDA. Обычно кандидаты задают технические вопросы по стеку, пайплайнам, иногда пытаются задать каверзные вопросы, особенно по плюсам, чтобы проверить нас. Иногда мы не можем ответить на них. Вопросы в стиле Google — например, «почему таблетки круглые?» — тоже встречаются, но недавно на одном из интервью прозвучал вопрос, на который вроде все и знали ответ, но никто сразу не смог его дать. Вопрос звучал так: «Какие общие технологии и решения появились в процессорах с времён 486, которыми мы часто пользуемся?»

Вопрос действительно интересный — что нового появилось, чем мы пользуемся каждый день? Что умеют современные процессоры, чего не могли процессоры год или два назад, пять или десять лет назад, сорок лет назад? Мы просто используем миллиарды транзисторов, даже не зная, как они работают. Покопавшись в Википедии, на сайте Агнера Фога и в документации Intel, я составил список того, что появилось и используется в современных процессорах. Всё, что указано ниже, относится в основном к x86 и консолям, если не указано иное. Поскольку консоли после третьего поколения PlayStation — фактически ПК с минимальными отличиями, речь дальше пойдёт в основном о ПК. История имеет склонность повторяться, и многое из того, что мы сейчас имеем, вводилось не один раз, просто под разными названиями.

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

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

Привет, Хабр! По нашему опыту, при разработке интеграционного взаимодействия труднее всего даётся сопоставление различных форматов данных интегрируемых систем — «маппинг». Для этого нужно проанализировать много форматов, выявить корректные связи между элементами XSD- или JSON-схем и описать правила преобразования. Работа кропотливая, трудозатратная и не самая интересная. Раньше нам приходилось вручную сводить в таблицах поля, сидеть ночами. Думаю, все аналитики с этим сталкиваются и понимают, о чём я говорю.

Меня зовут Ярослав, я техлид в Т1 Иннотех. Наша команда занимается интеграцией всевозможных систем и разработкой ядра интеграционной платформы. За последние три года мы успешно заменили решение на стеке IBM MQ и IBM App Connect (бывший IBM Integration BUS) на open-source решение на основе ActiveMQ Artemis в качестве транспорта, с использованием Java и Kubernetes, и перенесли более 1500 различных способов взаимодействий на новую платформу. Хочу поделиться с вами нашим опытом по автоматизации этой работы и обсудить получившийся инструмент.

Недавно я с удивлением обнаружил, что, оказывается, толковых туториалов по Oracle Application Express (он же APEX, он же апекс, но не путать с языком apex, который используется в Salesforce) в природе не существует.

Это не самая распространенная технология, конечно, но, тем не менее, довольно востребованная. Есть десятки блогов об апексе (англоязычные, в основном), пара тысяч вопросов на Stackoveflow, специальный раздел по апексу на официальных форумах оракла, сам апекс существует уже 15 лет и все время развивается. Я был уверен, что и хороших туториалов полно. Но нет!

Мне тут же пришла в голову гениальная мысль восполнить этот пробел.

Оглавление

Почему существующие туториалы — плохие
Вводная информация
Обзор IDE
    App builder
        Страница приложения
        Application properties
        Shared Components
        Page Designer
    SQL Workshop
        Object Browser
        SQL Commands

Хабр, привет!

Меня расстраивает несправедливость в мире IT: для новичков-разработчиков есть куча пошаговых инструкций, о там, как разработать API или мобильное приложение. Хочу немного уровнять баланс вселенной, поэтому я написал небольшой гайд для аналитиков для составления документации.

В прошлой статье я представил шаблон, а теперь заполнил его для фичи «Экспресс-доставка товара в маркетплейсе». Моя цель – показать, как можно вести документацию и как правильно заполнять этот шаблон.

DNS (Domain Name System) – это система, которая переводит понятные человеку доменные имена в IP-адреса, которые используют компьютеры для связи друг с другом. Представьте, что DNS – это как телефонная книга интернета. В обычной телефонной книге, если вам нужно найти номер телефона человека, вы ищете его по имени, и книга предоставляет вам номер. Точно так же DNS помогает находить IP-адреса, когда вы вводите доменное имя.

Когда вы вводите адрес веб-сайта, например, www.example.com, в строку браузера, DNS помогает найти нужный IP-адрес, чтобы ваш браузер мог подключиться к нужному серверу. IP-адрес – это уникальный числовой идентификатор, который используется для идентификации устройства в сети. Всякий раз, когда вы отправляете запрос на веб-сайт, ваш браузер отправляет этот запрос через интернет на сервер, который затем отвечает данными, которые вы видите на экране.

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

Введение

Привет, Хабр, меня зовут Светлана Уварова, я — ведущий системный архитектор в МТС.

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

Привет, Хабр! Меня зовут Андрей Царев — я системный аналитик, технический интервьюер и ментор.

Системный анализ — одно из популярных направлений в ИТ.

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

Многие из вас, я уверен, слышали о теории игр в какой-то момент своей жизни. Если вы хотите выглядеть умным и произвести впечатление на свою девушку — просто упомяните «игру с нулевой суммой» или «эволюционную стратегию», и ваши шансы отвести её домой сегодня вечером только что подскочили на 50%. Или вы можете использовать теорию игр, чтобы принимать решения в инвестировании своих денег (чтобы их полностью потерять и разориться) или, например решая, на какой девушке жениться (что также очень вероятно вас разорит). Как видите, это очень полезная теория.

Чтобы казаться умным - достаточно выучить эти пару выражений, но чтобы на самом деле что-то понимать - придется разобраться. Оказывается, это не так уж сложно и довольно интересно. Давайте посмотрим.

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

Сделать диаграммы привлекательными гораздо проще, чем вы думаете. Получить рекомендации на все случаи жизни не выйдет, но освоить несколько приемов в Excel и узнать азы теории, вы сможете за 10 минут. 

Из тридцатилетнего опыта и десятков прочитанных книг я выбрал семь полезных приемов. Их мы и разберем в этой статье в блоге ЛАНИТ.

У INCOSE (Международного совета по системной инженерии) в июне 2023 года вышла итоговая сводка по руководство по написанию требований (ссылка).

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

Данная статья - перевод с английского языка итоговой сводки по написанию требований.

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

Всем, привет.  Для самых жаждущих и нетерпеливых эта в этой статье будет про:

• Типы анализа, используемые для/около информационных технологий;

• Систему координат типов анализа и для чего использовать каждый из них;

• Специальные артефакты для каждого типа анализа;

• То, как понять, что в компании/процессе/проекте нужно использовать конкретный тип анализа;

• Акценты и навыки, нужные при использовании каждого типа анализа;

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

Рассуждая, что такое анализ, какой он бывает, какой тип, в каких условиях использовать и какие навыки нужны для того, чтобы его выполнять, я предположил, что будет полезным систематизировать имеющийся опыт и результаты обсуждения с коллегами, слушателями профессиональных программ развития НИУ ВШЭ, МИСИС, интернет университетов. Так появился следующий обзор. Надеюсь, он принесет вам пользу. Рассчитываю на обсуждение. Присоединяйтесь :-)

Лучший способ понять теорию — получить больше опыта в разных проектах. Для системных и бизнес‑аналитиков я постоянно показываю подходы к работе через публикацию разборов задач: БД, API, Интеграции, требования, и все, что связано с проектированием систем.

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

Решил составить для себя план развития (я в IT с 2007, как аналитик - с 2017). Что получилось: некий чек-лист с перечислением 13 блоков (от работы с требованиям до безопасности) с описанием, что обязательно и желательно знать/уметь.

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

Каждый системный и бизнес-аналитик проходит "боевое крещение" в своей карьере, когда получает первую задачу на проектирование интеграций. Звучит серьезно и сложно. И это так, если ни разу не работал с таким видом задач.

С чего начать и куда смотреть при работе с задачами на интеграции? Давайте воспользуемся пошаговой инструкцией, чтобы понять план действий.