Давайте подробно разберем, как работают индексы, на примере самого распространенного типа индекса в PostgreSQL – B-tree (сбалансированное дерево).
B-tree индекс – это, в некотором роде, иерархическая структура, напоминающая дерево. В начале у нас есть корневой узел, который в свою очередь ведет к нескольким дочерним узлам, и так далее до "листьев" этого дерева.
Есть прекрасный пример по игре "угадай число": Когда вы ищете число, например, 37, вместо того чтобы начать с первого числа и двигаться далее, как в переборе, вы бы задали вопрос: "Оно больше 25?". Если ответ "да", то вы переходите к дочернему узлу с большими числами. Далее: "Оно меньше 40?". Снова ответ "да", и вы двигаетесь ещё глубже в дерево.
Когда новые элементы добавляются или удаляются из базы данных, дерево значений "перебалансируется". Это значит, что структура дерева меняется таким образом, чтобы сохранить свою эффективность. Представьте, что у вас есть доска для игры в боулинг, и вы хотите, чтобы все кегли стояли в сбалансированном порядке. Если одна из кегель упала, вы быстро переставите остальные, чтобы сохранить равновесие.
Такой подход к поиску позволяет значительно сократить количество "шагов" или "вопросов", необходимых для нахождения нужной информации. Это как раз и является преимуществом B-tree: быстрый поиск, вставка и удаление данных.
Продолжение 👇
B-tree индекс – это, в некотором роде, иерархическая структура, напоминающая дерево. В начале у нас есть корневой узел, который в свою очередь ведет к нескольким дочерним узлам, и так далее до "листьев" этого дерева.
Есть прекрасный пример по игре "угадай число": Когда вы ищете число, например, 37, вместо того чтобы начать с первого числа и двигаться далее, как в переборе, вы бы задали вопрос: "Оно больше 25?". Если ответ "да", то вы переходите к дочернему узлу с большими числами. Далее: "Оно меньше 40?". Снова ответ "да", и вы двигаетесь ещё глубже в дерево.
Когда новые элементы добавляются или удаляются из базы данных, дерево значений "перебалансируется". Это значит, что структура дерева меняется таким образом, чтобы сохранить свою эффективность. Представьте, что у вас есть доска для игры в боулинг, и вы хотите, чтобы все кегли стояли в сбалансированном порядке. Если одна из кегель упала, вы быстро переставите остальные, чтобы сохранить равновесие.
Такой подход к поиску позволяет значительно сократить количество "шагов" или "вопросов", необходимых для нахождения нужной информации. Это как раз и является преимуществом B-tree: быстрый поиск, вставка и удаление данных.
Продолжение 👇
👍12❤2🔥2
Пример поиска по штрихкоду
Предположим, у нас есть индекс по полю barcode.
Как это работает без индекса:
Для каждого запроса поиска по штрихкоду, СУБД должна будет перебирать каждую строку в таблице (`full table scan`), что займет много времени при больших объемах данных - сотни тысяч записей записей в БД о товарах, для каждого зоомагазина.
Как это работает с индексом B-tree:
- Индекс B-tree можно представить как дерево, где каждый узел содержит значение и указатели на дочерние узлы.
- При запросе по штрихкоду, PostgreSQL начинает поиск с корневого узла дерева.
- Он сравнивает искомое значение штрихкода с значениями в узле.
- Если искомое значение меньше, PostgreSQL идет к левому дочернему узлу; если больше – к правому.
- Этот процесс повторяется, пока не будет найдена нужная запись или узел, который указывает на нее.
Пример поиска по названию товара
Как это работает с индексом B-tree:
- Когда клиент ищет определенный товар по названию, PostgreSQL будет использовать индекс по полю name.
- Алгоритм поиска аналогичен примеру с штрихкодом: СУБД начинает поиск с корневого узла дерева и двигается влево или вправо, сравнивая искомое значение с значениями в узле, пока не найдет нужную запись.
Ключевой момент в работе B-tree индекса – это способность быстро находить записи, даже на огромных объемах данных, путем систематического разделения данных на меньшие части (дерево). Вместо просмотра миллионов строк, СУБД может определить местоположение нужной строки, проверив всего лишь десяток или сотню узлов индекса. Это делает операции поиска намного быстрее 🤝🔑
Предположим, у нас есть индекс по полю barcode.
Как это работает без индекса:
Для каждого запроса поиска по штрихкоду, СУБД должна будет перебирать каждую строку в таблице (`full table scan`), что займет много времени при больших объемах данных - сотни тысяч записей записей в БД о товарах, для каждого зоомагазина.
Как это работает с индексом B-tree:
- Индекс B-tree можно представить как дерево, где каждый узел содержит значение и указатели на дочерние узлы.
- При запросе по штрихкоду, PostgreSQL начинает поиск с корневого узла дерева.
- Он сравнивает искомое значение штрихкода с значениями в узле.
- Если искомое значение меньше, PostgreSQL идет к левому дочернему узлу; если больше – к правому.
- Этот процесс повторяется, пока не будет найдена нужная запись или узел, который указывает на нее.
Пример поиска по названию товара
Как это работает с индексом B-tree:
- Когда клиент ищет определенный товар по названию, PostgreSQL будет использовать индекс по полю name.
- Алгоритм поиска аналогичен примеру с штрихкодом: СУБД начинает поиск с корневого узла дерева и двигается влево или вправо, сравнивая искомое значение с значениями в узле, пока не найдет нужную запись.
Ключевой момент в работе B-tree индекса – это способность быстро находить записи, даже на огромных объемах данных, путем систематического разделения данных на меньшие части (дерево). Вместо просмотра миллионов строк, СУБД может определить местоположение нужной строки, проверив всего лишь десяток или сотню узлов индекса. Это делает операции поиска намного быстрее 🤝🔑
👍18
Что использовать для проектирования БД - диаграмму классов UML или ER-диаграмму?
Вопрос с подвохом, хорош для собеседований.
Давайте разберем различия диаграммы классов UML или ER-диаграммы, и определим, для каких целей используется каждая из них.
Диаграмма классов UML
Это графическое представление структуры программного кода системы, создаваемой согласно принципам объектно-ориентированного программирования (далее - ООП), которое показывает классы, их атрибуты, методы и взаимосвязи между ними.
Элементы:
🔶 Классы программного кода (представлены прямоугольниками).
🔶 Атрибуты (свойства / переменные) программного кода (находятся внутри прямоугольника класса, сверху).
🔶 Методы программного кода (находятся внутри прямоугольника класса, снизу).
🔶 Взаимосвязи (стрелки между классами: ассоциация, наследование и др.).
Назначение:
Показывает как организовать структуру программного кода в системе.
Пример:
У нас есть класс "Пользователь" с атрибутами "имя", "электронная почта" и методом "заказать". Он связан с классом "Заказ", который содержит информацию о покупках.
ER-диаграмма (Entity-Relationship Diagram)
Это графическое представление структуры базы данных. Показывает сущности, их атрибуты и связи между сущностями.
Элементы:
🔶 Сущности (представлены прямоугольниками).
🔶 Атрибуты (находятся внутри прямоугольника сущности).
🔶 Связи (стрелки между сущностями).
Назначение:
Помогает разработчикам и аналитикам создавать и описывать структуру БД.
Пример:
У нас есть сущность "Пользователь" с атрибутами "имя" и "электронная почта". Эта сущность связана с сущностью "Заказ", который включает в себя номер, дату оформления, а также связан с различными товарами. Методов нет.
⬇️⬇️⬇️⬇️⬇️
Вопрос с подвохом, хорош для собеседований.
Давайте разберем различия диаграммы классов UML или ER-диаграммы, и определим, для каких целей используется каждая из них.
Диаграмма классов UML
Это графическое представление структуры программного кода системы, создаваемой согласно принципам объектно-ориентированного программирования (далее - ООП), которое показывает классы, их атрибуты, методы и взаимосвязи между ними.
Элементы:
🔶 Классы программного кода (представлены прямоугольниками).
🔶 Атрибуты (свойства / переменные) программного кода (находятся внутри прямоугольника класса, сверху).
🔶 Методы программного кода (находятся внутри прямоугольника класса, снизу).
🔶 Взаимосвязи (стрелки между классами: ассоциация, наследование и др.).
Назначение:
Показывает как организовать структуру программного кода в системе.
Пример:
У нас есть класс "Пользователь" с атрибутами "имя", "электронная почта" и методом "заказать". Он связан с классом "Заказ", который содержит информацию о покупках.
ER-диаграмма (Entity-Relationship Diagram)
Это графическое представление структуры базы данных. Показывает сущности, их атрибуты и связи между сущностями.
Элементы:
🔶 Сущности (представлены прямоугольниками).
🔶 Атрибуты (находятся внутри прямоугольника сущности).
🔶 Связи (стрелки между сущностями).
Назначение:
Помогает разработчикам и аналитикам создавать и описывать структуру БД.
Пример:
У нас есть сущность "Пользователь" с атрибутами "имя" и "электронная почта". Эта сущность связана с сущностью "Заказ", который включает в себя номер, дату оформления, а также связан с различными товарами. Методов нет.
⬇️⬇️⬇️⬇️⬇️
❤9🔥8👍3🤩3
‼️ Отличия диаграммы классов UML от ER-диаграммы ‼️
🔹 Фокус:
UML-диаграмма классов сфокусирована на структуре кода программы, ER – на структуре базы данных.
🔹Использование:
UML-диаграмма классов применяется в объектно-ориентированной разработке, ER-диаграмма – при проектировании баз данных.
По факту, в реальных проектах UML-диаграмму классов не используют. Это избыточная документация, которая меняется в процессе разработки программного кода. При большом желании можно автоматически создать UML-диаграмму на основе кода, но такой потребности у нас пока ни разу не возникало.
🔹Семантика:
UML-диаграмма классов имеет богатый набор отношений (наследование, ассоциация, агрегация и др.), в то время как ER-диаграмма обычно ограничивается типами отношений (один-ко-многим, многие-ко-многим и т.д.).
UML-диаграмма классов имеет методы, в то время как ER-диаграмма их не содержит, т.к. описывает только данные в БД, но не операции над ними.
Диаграммы классов UML можно использовать для проектирования баз данных. Однако стоит помнить, что UML первоначально был разработан для описания структуры программного кода, а не для баз данных. Несмотря на это, многие элементы и связи на диаграмме классов могут быть перенесены в контекст проектирования баз данных.
Для проектирования баз данных более подходяща нотация моделирования это ER-диаграмма (Entity-Relationship diagram). Она создана специально для описания структуры баз данных.
🔹 Фокус:
UML-диаграмма классов сфокусирована на структуре кода программы, ER – на структуре базы данных.
🔹Использование:
UML-диаграмма классов применяется в объектно-ориентированной разработке, ER-диаграмма – при проектировании баз данных.
По факту, в реальных проектах UML-диаграмму классов не используют. Это избыточная документация, которая меняется в процессе разработки программного кода. При большом желании можно автоматически создать UML-диаграмму на основе кода, но такой потребности у нас пока ни разу не возникало.
🔹Семантика:
UML-диаграмма классов имеет богатый набор отношений (наследование, ассоциация, агрегация и др.), в то время как ER-диаграмма обычно ограничивается типами отношений (один-ко-многим, многие-ко-многим и т.д.).
UML-диаграмма классов имеет методы, в то время как ER-диаграмма их не содержит, т.к. описывает только данные в БД, но не операции над ними.
Диаграммы классов UML можно использовать для проектирования баз данных. Однако стоит помнить, что UML первоначально был разработан для описания структуры программного кода, а не для баз данных. Несмотря на это, многие элементы и связи на диаграмме классов могут быть перенесены в контекст проектирования баз данных.
Для проектирования баз данных более подходяща нотация моделирования это ER-диаграмма (Entity-Relationship diagram). Она создана специально для описания структуры баз данных.
👍22❤7
Что выбрать для проектирования БД: UML-диаграмму классов или ER-диаграмму?
ER-диаграмма для проектирования баз данных. В ней
💠 таблицы (сущности),
💠 поля (свойства сущностей),
💠 отношения между таблицами БД.
UML-диаграмма для описания струткуры кода. В ней
💠 классы (описывают группы однотипных объектов, как сущности),
💠 поля (свойства сущностей),
💠 методы (функции - что можно делать с объектами классов),
💠 отношения между классами.
Сохраните ссылку на статью с подробным разбором и примерами в избранное, чтобы уверенно отвечать на этот теоретический вопрос на собеседованиях ❤️ В ней вы найдете лайфхаки по использованию UML-диаграммы классов для описания БД, код для PlantUML-диаграмм классов и объектов, а такде картинки этих диаграмм.
ER-диаграмма для проектирования баз данных. В ней
💠 таблицы (сущности),
💠 поля (свойства сущностей),
💠 отношения между таблицами БД.
UML-диаграмма для описания струткуры кода. В ней
💠 классы (описывают группы однотипных объектов, как сущности),
💠 поля (свойства сущностей),
💠 методы (функции - что можно делать с объектами классов),
💠 отношения между классами.
Сохраните ссылку на статью с подробным разбором и примерами в избранное, чтобы уверенно отвечать на этот теоретический вопрос на собеседованиях ❤️ В ней вы найдете лайфхаки по использованию UML-диаграммы классов для описания БД, код для PlantUML-диаграмм классов и объектов, а такде картинки этих диаграмм.
getanalyst.ru
Что выбрать для проектирования БД: сравнение UML-диаграммы классов и ER-диаграммы
Подходит ли диаграмма классов UML для проектирования баз данных? Давайте разберемся и сравним ее с ER-диаграммой.
👍15❤3
О личном. О наболевшем. И о том, что не надо воспринимать всё близко к сердцу, как я.
Наконец-то побывала в отпуске. Провела практический вебинар по БД и на следующий же день улетела. Последний раз мне реально удалось отдохнуть от работы и отключиться на 100% от сети в первых числах января 2022. На 4 дня. В обычной жизни отдых максимум на 1.5 дня с постоянным подключением в проекты и ответами по чатам.
С мая я больше не веду личные соцсети. Отказалась в пользу себя. Потому что сделать сториз в инстаграм = 1 час времени, который можно потратить на реальный отдых. У меня и до этого не было времени на них. Но хотелось как-то еще показывать, что я успеваю жить: мини-поездки, гастрономические приключения, 2-3 перелета в месяц, спорт каждый день, прогулки у океана. Это всё остается. Просто телефон в стороне.
Больше 30 человек с которыми я сейчас лично работаю и общаюсь по всем проектам. Эффективный менеджмент? В процессе перехода к нему. Но чтобы всё получилось как есть в моей жизни сейчас, надо было работать за семерых. Мои рабочие дни это 8-14 часов в сутки, 6 дней в неделю. Кроме GetAnalyst у меня есть актуальные проекты, которые я веду. И внутри GetAnalyst тоже большая загрузка по обучению и коммуникациям. Не всегда удается всем оперативно отвечать. Еще и на двух языках.
Я искренне люблю свою работу, искренне предана своему делу. Я очень хочу успевать больше, делать лучшее. Но иногда эта любовь переходит границы работа-жизнь. Я счастлива! Особенно тому, что я вижу результаты! Везде! Пусть и не так быстро, как хочется. Но такие нагрузки, которые я переношу, не пожелаю никому.
Всё не поместилось, продолжение в следующем посте 👇
Наконец-то побывала в отпуске. Провела практический вебинар по БД и на следующий же день улетела. Последний раз мне реально удалось отдохнуть от работы и отключиться на 100% от сети в первых числах января 2022. На 4 дня. В обычной жизни отдых максимум на 1.5 дня с постоянным подключением в проекты и ответами по чатам.
С мая я больше не веду личные соцсети. Отказалась в пользу себя. Потому что сделать сториз в инстаграм = 1 час времени, который можно потратить на реальный отдых. У меня и до этого не было времени на них. Но хотелось как-то еще показывать, что я успеваю жить: мини-поездки, гастрономические приключения, 2-3 перелета в месяц, спорт каждый день, прогулки у океана. Это всё остается. Просто телефон в стороне.
Больше 30 человек с которыми я сейчас лично работаю и общаюсь по всем проектам. Эффективный менеджмент? В процессе перехода к нему. Но чтобы всё получилось как есть в моей жизни сейчас, надо было работать за семерых. Мои рабочие дни это 8-14 часов в сутки, 6 дней в неделю. Кроме GetAnalyst у меня есть актуальные проекты, которые я веду. И внутри GetAnalyst тоже большая загрузка по обучению и коммуникациям. Не всегда удается всем оперативно отвечать. Еще и на двух языках.
Я искренне люблю свою работу, искренне предана своему делу. Я очень хочу успевать больше, делать лучшее. Но иногда эта любовь переходит границы работа-жизнь. Я счастлива! Особенно тому, что я вижу результаты! Везде! Пусть и не так быстро, как хочется. Но такие нагрузки, которые я переношу, не пожелаю никому.
Всё не поместилось, продолжение в следующем посте 👇
❤31🔥5👏2👍1
Обычно я успеваю писать контент в канал на 1-2 дня вперед, или пишу день в день. Чтобы заготовить посты в канал на 1 неделю я посвятила примерно 10 часов = 25% рабочей недели. Это детальные разборы примеров, это полный цикл информации, который можно было выдать по одному из направлений системного анализа.
Будучи в отпуске, когда добровольно-принудительно меня лишили ноутбука, в оставшемся в руках телефоне я вижу уведомления к публикующимся постам. Комментарии: "разбери детальнее", "почему так мало, давай еще больше", "инфоцыганство" и так далее. То, что такого рода сообщения дойдут и до меня - ожидаемо. И это скорее хорошо, чем плохо. Но обидно, правда, с учетом того, сколько сил я вкладываю. И особенно неприятно это было видеть в процессе отдыха.
К чему этот пост? То, что я передаю на открытых вебинарах и в канале - это база с практическим применением. И в таком объеме подобной последовательной информации по системному анализу больше нигде, кроме как здесь, нет.
Еще глубже - есть куда, я даю это в программах по навыкам для системных аналитиков: БД и SQL, Интеграции, REST API, освоить каждый из которых можно за 1.5-2 месяца реальной работы, я отвечаю на все вопросы. И на большой программе для начинающих в системном анализе.
Я хочу продолжать работать в удовольствие. Я хочу выбирать только те проекты, что мне в радость. Недостатка в работе у меня никогда не было и не будет. Есть цели - иду к ним. То, что передавать знания и писать меня радует - это везение, и получать от этого негативные эмоции я не выбираю. Я выбираю свой рост и помощь тем, кто ее ценит, и кому она действительно нужна.
Спасибо за внимание ❤️🙌
Будучи в отпуске, когда добровольно-принудительно меня лишили ноутбука, в оставшемся в руках телефоне я вижу уведомления к публикующимся постам. Комментарии: "разбери детальнее", "почему так мало, давай еще больше", "инфоцыганство" и так далее. То, что такого рода сообщения дойдут и до меня - ожидаемо. И это скорее хорошо, чем плохо. Но обидно, правда, с учетом того, сколько сил я вкладываю. И особенно неприятно это было видеть в процессе отдыха.
К чему этот пост? То, что я передаю на открытых вебинарах и в канале - это база с практическим применением. И в таком объеме подобной последовательной информации по системному анализу больше нигде, кроме как здесь, нет.
Еще глубже - есть куда, я даю это в программах по навыкам для системных аналитиков: БД и SQL, Интеграции, REST API, освоить каждый из которых можно за 1.5-2 месяца реальной работы, я отвечаю на все вопросы. И на большой программе для начинающих в системном анализе.
Я хочу продолжать работать в удовольствие. Я хочу выбирать только те проекты, что мне в радость. Недостатка в работе у меня никогда не было и не будет. Есть цели - иду к ним. То, что передавать знания и писать меня радует - это везение, и получать от этого негативные эмоции я не выбираю. Я выбираю свой рост и помощь тем, кто ее ценит, и кому она действительно нужна.
Спасибо за внимание ❤️🙌
❤47👍11🔥5
Как посмотреть ER-диаграмму для готовой базы данных? А еще где делать SQL-запросы.
ER-модель готовой базы данных – физический уровень модели данных.
Если Вам необходимо подключиться к существующей IT-системе и посмотреть ER-модель, то я рекомендую воспользоваться одним из инструментов:
🔶 DBeaver.
🔶 DataGrip.
🔶 DBVis.
Эти инструменты поддерживают подключение к 15+ СУБД, таким как MySQL, PostgreSQL, Oracle и другим.
Самый удобный инструмент, который довелось использовать для визуализации ER-диаграммы готовой БД, DBeaver.
🟢 регулярно обновляется,
🟢 бесплатный,
🟢 интуитивно понятный,
🟢 поддерживает русский язык.
Инструкцию по использованию DBeaver для визуализации ER-диаграммы реальной БД можно посмотреть в моей статье 🙂
ER-модель готовой базы данных – физический уровень модели данных.
Если Вам необходимо подключиться к существующей IT-системе и посмотреть ER-модель, то я рекомендую воспользоваться одним из инструментов:
🔶 DBeaver.
🔶 DataGrip.
🔶 DBVis.
Эти инструменты поддерживают подключение к 15+ СУБД, таким как MySQL, PostgreSQL, Oracle и другим.
Самый удобный инструмент, который довелось использовать для визуализации ER-диаграммы готовой БД, DBeaver.
🟢 регулярно обновляется,
🟢 бесплатный,
🟢 интуитивно понятный,
🟢 поддерживает русский язык.
Инструкцию по использованию DBeaver для визуализации ER-диаграммы реальной БД можно посмотреть в моей статье 🙂
❤11👍4
Главная ошибка кандидатов - отсутствие подготовки.
Подавляющее большинство аналитиков готовится примитивно: освежают в памяти свое резюме, дополняют его новым опытом, вспоминают задачи, теорию и размышляют о том, что можно рассказать о себе.
С таким подходом ваше интервью может быть успешным только если:
1. Вас уже ждут в этой компании.
2. Предложение компании по ЗП и условиям не соответствует рынку.
Чтобы подготовка была по настоящему эффективной:
1. Сформулируйте ваш опыт и навыки в краткой форме и подготовьтесь рассказать о них за 2 минуты.
2. Выделите конкретные кейсы, про которые сможете рассказать, демонстрирующие ваше участие в проектах в роли системного аналитика.
3. Подготовьтесь рассказывать о вашем взаимодействии с командой разработки и принятии решений.
4. Отрепетируйте ответы на типичные вопросы: лучшие и худшие качества, инструменты, которыми вы пользуетесь в процессе работы, ваше видение карьерного роста.
5. Готовьтесь к вопросам об опыте работы: причины смена компании, временные промежутки без работы в резюме, ваш опыт в различных сферах.
6. Подготовьте вопросы к работодателю: как выстроена работа, об ожиданиях от вас и о деталях предстоящих проектов.
7. Будьте готовы обсудить условия труда: размер ЗП, дополнительные льготы, как мед. страхование и абонемент в спортзал, возможность переезда и др.
8. Подготовьтесь к ответам на теоретические вопросы и к решению практических задач. Лучше всего, когда Вы с ходу рассказываете теорию на конкретных примерах из вашего опыта на работе или учебе.
Хотите быть готовы к интервью на высшем уровне? Используйте эти рекомендации, актуализируйте и структурируйте знания не только на проектах в компании, но и за ее пределами: обучения, книги, статьи, конференции. Многие, кто проходит обучение GetAnalyst, отмечают, что их уровень профессионального самосознания существенно вырос.
Актуальные знания дают уверенность и помогают не только на интервью, но и в текущих проектах 🙌
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥22👍7❤4
#GAfrindlyreminder от команды GetAnalyst:
Разомните шею, потянитесь и выпрямите спину, ведь позвоночник — это стебель жизни 🌱
Отличного вам настроения! 🌝
Разомните шею, потянитесь и выпрямите спину, ведь позвоночник — это стебель жизни 🌱
Отличного вам настроения! 🌝
😁33❤7👍1
Возможно, вы слышали о Full stack (фуллстек) разработчиках – универсальных специалистах, которые умеют писать код для фронтенда (тем, что пользователь видит в приложении), и для бэкенда (скрытой частью приложения).
Они также могут создавать базовый дизайн интерфейса, анализировать требования, тестировать приложения и делать релизы в продакшн для пользователей. Казалось бы, где найти более универсального героя в сфере IT?!
Но если роль Full stack разработчика давно узнаваема, то что вы скажете на счет... Full stack системного аналитика? 🐙
Понятие "Full stack разработчик" существует давно, как в сленге, так и в вакансиях, а "Full stack аналитик" пока еще не закрепило свои позиции. А надо бы, согласны? 😁👍
💥 Full stack аналитик 💥 - это специалист, который может работать на разных этапах разработки программного обеспечения, начиная от исследования потребностей бизнеса и определения требований до проектирования архитектуры системы.
Они также могут создавать базовый дизайн интерфейса, анализировать требования, тестировать приложения и делать релизы в продакшн для пользователей. Казалось бы, где найти более универсального героя в сфере IT?!
Но если роль Full stack разработчика давно узнаваема, то что вы скажете на счет... Full stack системного аналитика? 🐙
Понятие "Full stack разработчик" существует давно, как в сленге, так и в вакансиях, а "Full stack аналитик" пока еще не закрепило свои позиции. А надо бы, согласны? 😁👍
💥 Full stack аналитик 💥 - это специалист, который может работать на разных этапах разработки программного обеспечения, начиная от исследования потребностей бизнеса и определения требований до проектирования архитектуры системы.
👍17🔥6❤1
💥 Full stack аналитик💥 работает с задачами примерно в такой последовательности:
1. Общается с бизнес-заказчиком, изучает потребности бизнеса.
После анализа определяет необходимые доработки и разрабатывает бизнес-требования к системе.
2. Далее, на этапе проектирования, full stack аналитик создает технические задания - задачи на разработчиков, выбирает технологии с командой архитекторов и разработчиков, обсуждает вопросы архитектуры, определяет необходимые модули и функциональность, создает схемы БД, дизайны API, исследуют API других систем для интеграций, тестируют системы конкурентов, ставят задачи на дизайн.
*Это сколько всего знать нужно?! 😰
3. После этого этапа проектирования, аналитик тесно сотрудничает с командой разработчиков и тестировщиков, контролируя соответствие реализации установленным требованиям. Он также может координировать работу команды, выступая в роли менеджера проекта.
4. Если нужно, то при передаче решения в тестирование, он сам протестируют функциональность и запустит релиз в продакшн.
5. Когда система запущена и активно используется, аналитик готов анализировать данные, реагировать на проблемы и общаться с командой технической поддержки, исследовать логи (журнал работы системы) и координировать действия по устранению ошибок.
Full Stack аналитик - центральное звено в команде разработки, объединяющее бизнес-анализ, системный анализ, проектирование архитектуры и координацию работы различных команд. Это роль, требующая широкого спектра навыков и представляющая огромный потенциал для профессионального роста в IT.
Full stack системный аналитик - это человек в сфере IT, который умеет все, кроме программирования (но это не точно, некоторые аналитики умеют программировать, но не берут на себя эту ответственность). Это явно профессия будущего. А еще и крутые возможности для роста.
❤️ - если узнали себя в этом тексте, 🔥 - если растете в Full stack системного аналитика
1. Общается с бизнес-заказчиком, изучает потребности бизнеса.
После анализа определяет необходимые доработки и разрабатывает бизнес-требования к системе.
2. Далее, на этапе проектирования, full stack аналитик создает технические задания - задачи на разработчиков, выбирает технологии с командой архитекторов и разработчиков, обсуждает вопросы архитектуры, определяет необходимые модули и функциональность, создает схемы БД, дизайны API, исследуют API других систем для интеграций, тестируют системы конкурентов, ставят задачи на дизайн.
*Это сколько всего знать нужно?! 😰
3. После этого этапа проектирования, аналитик тесно сотрудничает с командой разработчиков и тестировщиков, контролируя соответствие реализации установленным требованиям. Он также может координировать работу команды, выступая в роли менеджера проекта.
4. Если нужно, то при передаче решения в тестирование, он сам протестируют функциональность и запустит релиз в продакшн.
5. Когда система запущена и активно используется, аналитик готов анализировать данные, реагировать на проблемы и общаться с командой технической поддержки, исследовать логи (журнал работы системы) и координировать действия по устранению ошибок.
Full Stack аналитик - центральное звено в команде разработки, объединяющее бизнес-анализ, системный анализ, проектирование архитектуры и координацию работы различных команд. Это роль, требующая широкого спектра навыков и представляющая огромный потенциал для профессионального роста в IT.
Full stack системный аналитик - это человек в сфере IT, который умеет все, кроме программирования (но это не точно, некоторые аналитики умеют программировать, но не берут на себя эту ответственность). Это явно профессия будущего. А еще и крутые возможности для роста.
❤️ - если узнали себя в этом тексте, 🔥 - если растете в Full stack системного аналитика
❤43🔥24😱10👍6
API (Application Programming Interface) - это набор правил и протоколов, которые позволяют различным программам взаимодействовать друг с другом.
Когда разработчики создают приложение или сервис, они могут создать API, чтобы позволить другим приложениям использовать их функциональность.
Вот три простых примера про разработку и использование API:
🔑 Сервисы социальных сетей. Facebook, Instagram и Twitter предоставляют API, которые позволяют различным приложениям и сайтам получать доступ к данным пользователя, таким как профиль, фотографии и т.д. Это позволяет разработчикам создавать приложения, которые могут использовать данные из социальных сетей, например, для авторизации или для отображения фотографий.
🔑 Карты и местоположение. Google Maps и другие сервисы карт и местоположения также предоставляют API, которые позволяют другим приложениям использовать их функциональность. Например, мобильное приложение для заказа такси может использовать API Google Maps, чтобы определить местоположение пользователя и проложить маршрут.
🔑 Банковские сервисы. Банки также предоставляют API, которые позволяют другим приложениям получать доступ к данным о балансе, транзакциях и т.д. Это может использоваться, например, для создания приложений для управления личными финансами, которые позволяют пользователю просматривать свой баланс и транзакции из разных банков в одном месте.
API - это способ, с помощью которого различные приложения могут взаимодействовать друг с другом и использовать функциональность других сервисов и приложений.
API могут быть использованы для создания различных приложений, от социальных сетей до банковских сервисов, и предоставляют возможность интеграции различных приложений и сервисов.
Когда разработчики создают приложение или сервис, они могут создать API, чтобы позволить другим приложениям использовать их функциональность.
Вот три простых примера про разработку и использование API:
🔑 Сервисы социальных сетей. Facebook, Instagram и Twitter предоставляют API, которые позволяют различным приложениям и сайтам получать доступ к данным пользователя, таким как профиль, фотографии и т.д. Это позволяет разработчикам создавать приложения, которые могут использовать данные из социальных сетей, например, для авторизации или для отображения фотографий.
🔑 Карты и местоположение. Google Maps и другие сервисы карт и местоположения также предоставляют API, которые позволяют другим приложениям использовать их функциональность. Например, мобильное приложение для заказа такси может использовать API Google Maps, чтобы определить местоположение пользователя и проложить маршрут.
🔑 Банковские сервисы. Банки также предоставляют API, которые позволяют другим приложениям получать доступ к данным о балансе, транзакциях и т.д. Это может использоваться, например, для создания приложений для управления личными финансами, которые позволяют пользователю просматривать свой баланс и транзакции из разных банков в одном месте.
API - это способ, с помощью которого различные приложения могут взаимодействовать друг с другом и использовать функциональность других сервисов и приложений.
API могут быть использованы для создания различных приложений, от социальных сетей до банковских сервисов, и предоставляют возможность интеграции различных приложений и сервисов.
👍24❤4
Есть несколько распространённых видов API, каждый из которых предназначен для определённых задач и целей:
♦️REST API (Representational State Transfer) – это подход, акцентирующийся на использовании стандартных HTTP-протоколов и форматов данных, например, JSON или XML. REST API позволяет клиентам выполнять операции CRUD (создание, чтение, обновление, удаление) над ресурсами, представленными URL-адресами.
♦️SOAP API (Simple Object Access Protocol) – это протокол, который позволяет приложениям обмениваться структурированными данными через XML, используя также WSDL (Web Services Description Language) для описания интерфейсов веб-сервиса.
♦️GraphQL API – язык запросов, который позволяет клиентам запрашивать именно те данные, которые им нужны, получая их в оптимизированном формате, и часто возвращающий данные в формате JSON.
Пример: Запрос списка друзей пользователя в социальной сети, с получением в ответ только имён и изображений профилей.
♦️gRPC – это протокол, облегчающий выполнение удалённых вызовов процедур (RPC), используя для этого бинарный протокол сериализации, что позволяет обмениваться данными быстро и эффективно.
Пример: Использование gRPC для обмена данными между микросервисами в распределенной системе.
♦️WebSocket API – протокол, который позволяет установить постоянное соединение между клиентом и сервером, обеспечивая обмен данными в реальном времени без необходимости отправки повторных запросов.
Пример: Чат-приложение, где сервер и клиент обмениваются сообщениями в реальном времени через WebSocket соединение.
Существует также множество других типов API, таких как XML-RPC, JSON-RPC, HAL, OData и др. Каждый тип API имеет свои особенности, и выбор между ними зависит от конкретной задачи и требований к проекту.
Если вы освоите работу с REST API, то, безусловно, почувствуете себя комфортнее в сфере разработки, поскольку это один из наиболее распространенных и широко применяемых видов API на сегодняшний день. А с его глубоким пониманием гораздо проще осваивать остальные протоколы.
♦️REST API (Representational State Transfer) – это подход, акцентирующийся на использовании стандартных HTTP-протоколов и форматов данных, например, JSON или XML. REST API позволяет клиентам выполнять операции CRUD (создание, чтение, обновление, удаление) над ресурсами, представленными URL-адресами.
♦️SOAP API (Simple Object Access Protocol) – это протокол, который позволяет приложениям обмениваться структурированными данными через XML, используя также WSDL (Web Services Description Language) для описания интерфейсов веб-сервиса.
♦️GraphQL API – язык запросов, который позволяет клиентам запрашивать именно те данные, которые им нужны, получая их в оптимизированном формате, и часто возвращающий данные в формате JSON.
Пример: Запрос списка друзей пользователя в социальной сети, с получением в ответ только имён и изображений профилей.
♦️gRPC – это протокол, облегчающий выполнение удалённых вызовов процедур (RPC), используя для этого бинарный протокол сериализации, что позволяет обмениваться данными быстро и эффективно.
Пример: Использование gRPC для обмена данными между микросервисами в распределенной системе.
♦️WebSocket API – протокол, который позволяет установить постоянное соединение между клиентом и сервером, обеспечивая обмен данными в реальном времени без необходимости отправки повторных запросов.
Пример: Чат-приложение, где сервер и клиент обмениваются сообщениями в реальном времени через WebSocket соединение.
Существует также множество других типов API, таких как XML-RPC, JSON-RPC, HAL, OData и др. Каждый тип API имеет свои особенности, и выбор между ними зависит от конкретной задачи и требований к проекту.
Если вы освоите работу с REST API, то, безусловно, почувствуете себя комфортнее в сфере разработки, поскольку это один из наиболее распространенных и широко применяемых видов API на сегодняшний день. А с его глубоким пониманием гораздо проще осваивать остальные протоколы.
👍32🔥10❤3🥰2
Подробные примеры по видам API ✌️
Давайте рассмотрим пример запроса информации о налогоплательщике по его ИНН (идентификационный номер налогоплательщика) для каждого вида API.
📐 REST API
Запрос:
⌨️ http
Ответ:
⌨️ JSON
-----------------------------
📐 SOAP API
Запрос:
⌨️
Ответ:
⌨️
-----------------------------
👇👇👇
Давайте рассмотрим пример запроса информации о налогоплательщике по его ИНН (идентификационный номер налогоплательщика) для каждого вида API.
📐 REST API
Запрос:
⌨️ http
GET https://api.taxservice.com/taxpayer/1234567890Ответ:
⌨️ JSON
{
"inn": "1234567890",
"name": "Иванов Иван Иванович",
"registered": "2020-01-01",
"status": "active"
}-----------------------------
📐 SOAP API
Запрос:
⌨️
xml
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:tax="http://api.taxservice.com/">
<soapenv:Header/>
<soapenv:Body>
<tax:GetTaxpayerInfo>
<tax:ИНН>1234567890</tax:ИНН>
</tax:GetTaxpayerInfo>
</soapenv:Body>
</soapenv:Envelope>Ответ:
⌨️
xml
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:tax="http://api.taxservice.com/">
<soapenv:Body>
<tax:GetTaxpayerInfoResponse>
<tax:Taxpayer>
<tax:ИНН>1234567890</tax:ИНН>
<tax:ФИО>Иванов Иван Иванович</tax:ФИО>
<tax:Дата регистрации>01.01.2020</tax:Дата регистрации>
<tax:Статус>active</tax:Статус>
</tax:Taxpayer>
</tax:GetTaxpayerInfoResponse>
</soapenv:Body>
</soapenv:Envelope>-----------------------------
👇👇👇
❤27👍11👏1
📐 GraphQL API
Запрос:
⌨️
Ответ:
⌨️
-----------------------------
📐 gRPC
Для gRPC сначала требуется описание протокола в .proto файле:
⌨️ protobuf
Запрос (клиентский код на Python, например):
⌨️python
Ответ (представлен в виде объекта):
⌨️python
-----------------------------
👇👇👇
Запрос:
⌨️
graphql
{
taxpayer(inn: "1234567890") {
inn
name
registered
status
}
}Ответ:
⌨️
json
{
"data": {
"taxpayer": {
"inn": "1234567890",
"name": "Иванов Иван Иванович",
"registered": "2020-01-01",
"status": "active"
}
}
}-----------------------------
📐 gRPC
Для gRPC сначала требуется описание протокола в .proto файле:
⌨️ protobuf
syntax = "proto3";
package taxservice;
service TaxService {
rpc GetTaxpayerInfo (TaxpayerRequest) returns (TaxpayerInfo);
}
message TaxpayerRequest {
string inn = 1;
}
message TaxpayerInfo {
string inn = 1;
string name = 2;
string registered = 3;
string status = 4;
}Запрос (клиентский код на Python, например):
⌨️python
import grpc
import taxservice_pb2
import taxservice_pb2_grpc
channel = grpc.insecure_channel('api.taxservice.com:50051')
stub = taxservice_pb2_grpc.TaxServiceStub(channel)
response = stub.GetTaxpayerInfo(taxservice_pb2.TaxpayerRequest(inn="1234567890"))
print(response)
Ответ (представлен в виде объекта):
⌨️python
inn: "1234567890"
name: "Иванов Иван Иванович"
registered: "2020-01-01"
status: "active"-----------------------------
👇👇👇
❤20👎2
📐WebSocket API
WebSocket, как правило, используется для двустороннего взаимодействия, поэтому здесь будет инициировано соединение, затем отправлен запрос, и в ответ придет нужная информация.
Запрос (пример на JavaScript):
⌨️ javascript
Ответ (полученный от сервера):
⌨️ json
-----------------------------
Приведенные выше примеры упрощены и служат только для демонстрации различий в подходах каждого типа API. В реальных приложениях могут требоваться дополнительные настройки, авторизация и другие параметры, влияющие на процесс обработки запросов 🙌
WebSocket, как правило, используется для двустороннего взаимодействия, поэтому здесь будет инициировано соединение, затем отправлен запрос, и в ответ придет нужная информация.
Запрос (пример на JavaScript):
⌨️ javascript
let socket = new WebSocket("wss://api.taxservice.com/taxpayers");
socket.onopen = function(event) {
let requestData = {
action: "getTaxpayerInfo",
inn: "1234567890"
};
socket.send(JSON.stringify(requestData));
};
socket.onmessage = function(event) {
let responseData = JSON.parse(event.data);
console.log(responseData);
};
Ответ (полученный от сервера):
⌨️ json
{
"action": "taxpayerInfo",
"data": {
"inn": "1234567890",
"name": "Иванов Иван Иванович",
"registered": "2020-01-01",
"status": "active"
}
}-----------------------------
Приведенные выше примеры упрощены и служат только для демонстрации различий в подходах каждого типа API. В реальных приложениях могут требоваться дополнительные настройки, авторизация и другие параметры, влияющие на процесс обработки запросов 🙌
🔥14❤4👍3
‼️ Важны примеры-образцы: открытые протоколы API ‼️
Реальный мир 🌎 Для каждого из протоколов я хочу дать вам ссылки на публичную документацию к API известных компаний и популярных проектов.
🔹REST API
Spotify: Музыкальная стриминговая платформа Spotify предоставляет RESTful API, который позволяет разработчикам создавать приложения, которые взаимодействуют с каталогом Spotify, плейлистами, артистами и многим другим.
Spotify Web API
🔹SOAP API
PayPal: Для некоторых из своих сервисов PayPal предоставляет SOAP API, позволяя интегрировать возможности оплаты и управления транзакциями.
PayPal SOAP API
Пример метода получения баланса для удобства.
🔹GraphQL API
Shopify: Shopify использует GraphQL для предоставления гибкого и эффективного способа взаимодействия с их платформой электронной коммерции.
Shopify GraphQL API
🔹gRPC
Google Cloud: Многие сервисы Google Cloud Platform предоставляют gRPC API. Например, сервис Bigtable от Google имеет такой интерфейс.
Google Cloud Bigtable gRPC API
🔹WebSocket API
Binance: Биржа криптовалют Binance предоставляет WebSocket API для мгновенного получения информации о торговле.
Binance WebSocket API Documentation
Сохраняйте в избранное на будущее, чтобы иметь примеры всех видов API документации под рукой, и делитесь с коллегами аналитиками, кто интересовался темой API 🤝
Реальный мир 🌎 Для каждого из протоколов я хочу дать вам ссылки на публичную документацию к API известных компаний и популярных проектов.
🔹REST API
Spotify: Музыкальная стриминговая платформа Spotify предоставляет RESTful API, который позволяет разработчикам создавать приложения, которые взаимодействуют с каталогом Spotify, плейлистами, артистами и многим другим.
Spotify Web API
🔹SOAP API
PayPal: Для некоторых из своих сервисов PayPal предоставляет SOAP API, позволяя интегрировать возможности оплаты и управления транзакциями.
PayPal SOAP API
Пример метода получения баланса для удобства.
🔹GraphQL API
Shopify: Shopify использует GraphQL для предоставления гибкого и эффективного способа взаимодействия с их платформой электронной коммерции.
Shopify GraphQL API
🔹gRPC
Google Cloud: Многие сервисы Google Cloud Platform предоставляют gRPC API. Например, сервис Bigtable от Google имеет такой интерфейс.
Google Cloud Bigtable gRPC API
🔹WebSocket API
Binance: Биржа криптовалют Binance предоставляет WebSocket API для мгновенного получения информации о торговле.
Binance WebSocket API Documentation
Сохраняйте в избранное на будущее, чтобы иметь примеры всех видов API документации под рукой, и делитесь с коллегами аналитиками, кто интересовался темой API 🤝
🔥35👍6❤2
Погружаемся в REST API 😎
REST API - это архитектурный стиль, который определяет, по каким правилам приложения должны обмениваться данными между собой. Он используется для создания веб-сервисов, мобильных приложений, интеграционных платформ и других IT-решений.
Его главная цель - облегчить передачу информации между разными системами и управлять ей: создавать, читать, изменять, удалять. REST API использует для этого стандартные HTTP-запросы: GET, POST, PUT, DELETE и другие.
Важно отметить разницу, важно для собеседований:
🔹 REST API - это архитектурный стиль проектирования взаимодействия приложений.
🔹 HTTP - протокол, на основе которого работает REST API.
Еще пример: у национального аэрокосмического управления США (NASA) есть REST API, который предоставляет доступ к различной информации о космических миссиях, астрономических событиях и многом другом.
Ссылка на документацию API NASA 🔗
Отличие REST API от других видов API, таких как SOAP API, ftp и RPC, заключается в том, что REST API не имеет жестких правил и структур, и может быть использован с любым языком программирования - java, Python, C++ и другие.
SOAP API, например, требует использования XML формата сообщений для передачи данных и имеет строгие правила для определения объектов. В то время как REST API поддерживает форматы сообщений JSON, XML, HTML и другие.
REST API - это набор правил проектирования пограммных интерфейсов (API), введенный Роем Филдингом, одним из основных авторов спецификации HTTP: Ссылка на основополагающий документ.
Что еще вам интересно узнать про REST API? Пишите в комментарии 📝
REST API - это архитектурный стиль, который определяет, по каким правилам приложения должны обмениваться данными между собой. Он используется для создания веб-сервисов, мобильных приложений, интеграционных платформ и других IT-решений.
Его главная цель - облегчить передачу информации между разными системами и управлять ей: создавать, читать, изменять, удалять. REST API использует для этого стандартные HTTP-запросы: GET, POST, PUT, DELETE и другие.
Важно отметить разницу, важно для собеседований:
🔹 REST API - это архитектурный стиль проектирования взаимодействия приложений.
🔹 HTTP - протокол, на основе которого работает REST API.
Еще пример: у национального аэрокосмического управления США (NASA) есть REST API, который предоставляет доступ к различной информации о космических миссиях, астрономических событиях и многом другом.
Ссылка на документацию API NASA 🔗
Отличие REST API от других видов API, таких как SOAP API, ftp и RPC, заключается в том, что REST API не имеет жестких правил и структур, и может быть использован с любым языком программирования - java, Python, C++ и другие.
SOAP API, например, требует использования XML формата сообщений для передачи данных и имеет строгие правила для определения объектов. В то время как REST API поддерживает форматы сообщений JSON, XML, HTML и другие.
REST API - это набор правил проектирования пограммных интерфейсов (API), введенный Роем Филдингом, одним из основных авторов спецификации HTTP: Ссылка на основополагающий документ.
Что еще вам интересно узнать про REST API? Пишите в комментарии 📝
❤16🔥9👍5
REST является одним из наиболее популярных стилей для разработки веб-сервисов. Однако, как и любой инструмент или подход, REST не всегда является наилучшим выбором для всех сценариев.
Вот несколько ситуаций, в которых использование REST API может оказаться неверным решением:
❌ Непрерывное Взаимодействие в Реальном Времени:
Для приложений, требующих постоянного соединения для быстрого обмена данными в реальном времени (например, онлайн-игры, чаты), WebSocket или другие протоколы реального времени могут быть более подходящими.
❌ Клиенты требуют различных наборов данных: Если клиенты (например, мобильное приложение и веб-сайт) требуют разных наборов данных, GraphQL может предоставить больше гибкости, позволяя клиентам запрашивать только те данные, которые им нужны.
❌ Бинарный Протокол: Если требуется эффективность и минимальные затраты на передачу данных, то протоколы, такие как gRPC, которые используют бинарные форматы передачи данных, могут быть более эффективными.
❌ Служебная Информация: Если ваш API должен передавать много служебной информации вместе с данными (например, метаданными или инструкциями обработки), SOAP может быть более подходящим, так как он предоставляет стандартизированный способ включения такой информации в сообщения.
❌ Обратная Совместимость: Если ваша система уже имеет существующие интеграции на основе другого протокола (например, SOAP), и переход на REST может вызвать сбои или требует значительной переработки, может быть рационально продолжить использовать текущий протокол.
Хотя REST является мощным и гибким подходом для разработки API, всегда важно рассматривать требования конкретного проекта и решать вместе с разработчиками и архитекторами, какой вид API будет наиболее подходящим в данной ситуации.
Вот несколько ситуаций, в которых использование REST API может оказаться неверным решением:
❌ Непрерывное Взаимодействие в Реальном Времени:
Для приложений, требующих постоянного соединения для быстрого обмена данными в реальном времени (например, онлайн-игры, чаты), WebSocket или другие протоколы реального времени могут быть более подходящими.
❌ Клиенты требуют различных наборов данных: Если клиенты (например, мобильное приложение и веб-сайт) требуют разных наборов данных, GraphQL может предоставить больше гибкости, позволяя клиентам запрашивать только те данные, которые им нужны.
❌ Бинарный Протокол: Если требуется эффективность и минимальные затраты на передачу данных, то протоколы, такие как gRPC, которые используют бинарные форматы передачи данных, могут быть более эффективными.
❌ Служебная Информация: Если ваш API должен передавать много служебной информации вместе с данными (например, метаданными или инструкциями обработки), SOAP может быть более подходящим, так как он предоставляет стандартизированный способ включения такой информации в сообщения.
❌ Обратная Совместимость: Если ваша система уже имеет существующие интеграции на основе другого протокола (например, SOAP), и переход на REST может вызвать сбои или требует значительной переработки, может быть рационально продолжить использовать текущий протокол.
Хотя REST является мощным и гибким подходом для разработки API, всегда важно рассматривать требования конкретного проекта и решать вместе с разработчиками и архитекторами, какой вид API будет наиболее подходящим в данной ситуации.
👍34