Веб-камера

Лайфхак😁😂

🎯 Почему проваливаются IT-проекты? И при чем тут бизнес-анализ?

Многие из нас — аналитики, менеджеры, разработчики — не раз сталкивались с недоумением со стороны заказчиков. Зачем им какие-то «видения», «декомпозиции», «пользовательские истории» или «спецификации требований»? Часто на старте встречаешь один и тот же рефрен:

«Это все понятно… Но нам нужны просто разработчики».

И в каком-то смысле они правы: никакой бизнес-анализ сам по себе бизнесу не нужен. Как и не нужен продукт — пусть даже идеальный — если он не решает реальных проблем бизнеса и не нужен пользователям.

Но вот парадокс: разработчик не обязан разбираться, что именно нужно бизнесу. Его задача — реализовать решение. А искать и формулировать само решение — задача бизнес-аналитика. Это ключевое разделение, которое часто игнорируют. И в этом — источник катастроф.

📉 Немного статистики:

Исследование *The Standish Group* (2015) показало:
🔸 Лишь 29% IT-проектов завершились успешно.
🔸 83% проектов — провальные или спорные.
🔸 Только 15,5% проектов уложились в бюджет.
🔸 Только 13,9% — в сроки.
🔸 Лишь 7,3% реализовали весь запланированный функционал.

Причины? Те же исследования указывают на некачественные требования как ключевой фактор провала. А они — результат слабого бизнес-анализа или его полного отсутствия.

💰 Цена ошибки

Исправление ошибки, допущенной на этапе требований, может стоить в 10–100 раз дороже, если её обнаружат на стадии эксплуатации. Например, ошибка, стоившая 1000 \$ в начале проекта, может обойтись в 100 000 \$ ближе к релизу.

📌 Вывод

Игнорирование бизнес-анализа — не экономия, а рисковый шаг, способный пустить под откос весь проект.
Решение простое: не заменяйте бизнес-аналитика менеджером, разработчиком или “знаниями заказчика”. Заказчик может думать, что ему нужен самолет, хотя на самом деле нужен электросамокат. Кто это определит, если не аналитик?

И так всегда...

📌 Базы данных: просто о сложном для начинающих в IT

Базы данных (БД) — это фундамент большинства современных приложений. Но что это такое на практике? Давайте разберёмся на простых примерах!

🔷 Что такое БД и зачем она нужна?
Представьте интернет-магазин: когда вы делаете заказ, ваши данные (имя, адрес, заказ) сохраняются в базе данных. Без неё приложение не смогло бы запоминать пользователей, заказы или историю покупок.

👉 БД — это:
✔️ Упорядоченное хранилище данных (как Excel, но мощнее)
✔️ Основа клиент-серверных приложений (сайты, мобильные приложения)
✔️ Инструмент для быстрого поиска и обработки информации

🔷 Как устроена реляционная БД?
Самый распространённый тип — реляционные БД (MySQL, PostgreSQL). Данные в них хранятся в таблицацах, связанных между собой.

🔹 Пример:
- Таблица users — данные о клиентах
- Таблица orders — информация о заказах
- Связь между ними — user_id (чтобы знать, кто что заказал)

Ключевые элементы:
🔑 Primary Key (PK) — уникальный идентификатор (например, id пользователя)
🔗 Foreign Key (FK) — связь между таблицами (например, user_id в заказе)

🔷 SQL: язык общения с БД
Чтобы получить данные, нужно написать SQL-запрос. Например:

SELECT * FROM users WHERE name = 'Иван';

📌 Основные команды:
✔️ SELECT — выборка данных
✔️ INSERT — добавление новых записей
✔️ UPDATE — изменение данных
✔️ JOIN — объединение таблиц

#DBMS

Чуточку ниже)

💡 JSON (JavaScript Object Notation) — это текстовый формат для обмена данными. Он:

• легко читается человеком
• легко обрабатывается машиной
• поддерживается почти всеми языками программирования

Как устроен JSON?
JSON описывает данные в виде пар ключ: значение.

📦 JSON-объект — данные в фигурных скобках:

{
  "query": "Виктор Иван",
  "count": 7
}

• "query" и "count" — ключи
• "Виктор Иван" и 7 — значения
• Строки — в кавычках
• Числа, true, false, null — без кавычек

JSON-объект может содержать:
• другие объекты
• массивы
• строки
• числа
• булевы значения
• null

📚 Что такое массив в JSON?
📦 JSON-массив — упорядоченный список значений в квадратных скобках:

["MALE", "FEMALE"]

Пример с массивом внутри объекта:

{
  "parts": ["NAME", "SURNAME"]
}

Значения могут быть любого типа: строки, числа, объекты, массивы.

✅ Признаки валидного JSON:

• Все строки — в двойных кавычках
• Ключи — тоже в кавычках
• Пары ключ:значение разделены запятыми
• Объекты — в { }, массивы — в [ ]

Пример правильного JSON:

{
  "name": "Иван",
  "age": 30,
  "skills": ["Postman", "SQL", "Python"],
  "married": false
}

#api #postman #json #тестирование #qa

- а какие у вас сроки?
- через 2 недели за 1 день

🔌 Модель OSI — как устройства понимают друг друга в сети

Еще в 1977 году появилась идея объединить разные устройства и сети в единую систему общения. Так родилась модель OSI — концепция из 7 уровней, каждый из которых выполняет свою роль в передаче данных.

📡 Физический слой — ток, свет, радиоволны. Все начинается с передачи сигналов по проводам.
📦 Канальный слой — делит данные на кадры, проверяет на ошибки.
🧭 Сетевой слой — отвечает за маршруты и IP-адреса.
📨 Транспортный слой — гарантирует доставку данных.
🔄 Сеансовый слой — устанавливает и управляет соединением.
🧩 Презентационный слой — форматирует данные (например, шифрует или сжимает).
📱 Прикладной слой — интерфейс пользователя (браузер, почта и пр.).

📌 Хотя в 2024 модель OSI считается устаревшей, она легла в основу TCP/IP — реального "двигателя" интернета.

На удалёнке😉😂

🧩 Что такое SOAP API и зачем он нужен?

Когда вы слышите SOAP API, представьте не мыло, а почтовую службу. Настоящую, государственную — надёжную, стандартизованную, медленную, но строго по правилам. Именно такой протокол взаимодействия между приложениями предлагает SOAP (Simple Object Access Protocol).

SOAP появился в конце 90-х, когда бизнес начал активно передавать данные между корпоративными сетями. Он создавался не просто как архитектурный стиль (как REST), а как полноценный протокол обмена сообщениями, где важна не столько структура URL, сколько структура самого сообщения. SOAP использует XML и даёт жёстко определённый шаблон:
📦 Envelope — "конверт" с сообщением
🔐 Encoding — правила кодирования
📨 Request/Response — строгое тело запроса и ответа

🧠 Почему SOAP до сих пор в игре?

Несмотря на свою возрастную архитектуру, SOAP остаётся актуальным. Причины:

✅ Независим от языка и платформы: Java, .NET, Python — не важно.
✅ Безопасность: поддержка WS-Security делает его идеальным выбором для банков, госорганов, биллинговых систем.
✅ Работает через HTTP, но может и через SMTP, TCP, UDP — гибко.
✅ Хорошо себя чувствует в распределённых системах, где REST может давать сбои из-за своей «легковесности».

💥 А что не так с SOAP?

🔻 Нет кэширования — каждый вызов всегда заново.
🔻 Строгая структура = больше кода и времени на разработку.
🔻 Порог входа выше: нужен WSDL, генерация клиента, знание XML.
🔻 Обычно медленнее REST, особенно в вебе.

🎯 Где SOAP раскрывается на полную мощность?

* 💳 Банковские переводы — безопасность + взаимодействие между разными системами
* ✈️ Бронирование билетов — вызов множества внешних сервисов
* 📞 Биллинг в телекомах — сложные расчёты и конфиденциальные данные
* 🧭 Навигация и логистика — сбор данных из разных источников
* 🏙 Управление городом — от светофоров до канализации

📘 Пример SOAP API:
Сервис проверки ISBN книг. Вот как выглядит SOAP-запрос:

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <IsValidISBN10 xmlns="http://webservices.daehosting.com/ISBN">
      <sISBN>0-19-852663-6</sISBN>
    </IsValidISBN10>
  </soap:Body>
</soap:Envelope>

Ответ приходит в том же формате XML, внутри <soap:Envelope>, с логическим флагом <IsValidISBN10Result>true</IsValidISBN10Result>.

🔚 Вывод

SOAP — это не просто альтернатива REST. Это индустриальный стандарт, где ставка делается на надёжность, формализм и безопасность. Да, он не так гибок. Да, он не такой быстрый. Но если вам нужно интегрировать ядро банка, биллинг оператора или муниципальные сервисы — SOAP всё ещё остаётся тем самым протоколом, которому можно доверить критически важные данные.

#INTEGRATION

🔍 Как выбрать базу данных: краткий обзор типов СУБД

При проектировании системы важно правильно выбрать тип базы данных под конкретные задачи. Вот краткий гид по основным видам:

🔸 Реляционные СУБД — классика (PostgreSQL, MySQL). Данные хранятся в таблицах. Хорошо подходят для транзакционных и аналитических систем.

🔸 Key-Value базы — максимум скорости для кеширования и быстрого доступа к данным по ключу (Redis, Tarantool).

🔸 Документо-ориентированные — гибкость и масштабируемость при хранении JSON-подобных структур (MongoDB, YDB).

🔸 Временные ряды — идеальны для метрик, логов и IoT (Prometheus, InfluxDB).

🔸 Графовые — анализ связей между объектами: соцсети, финансы, телеком (Neo4j).

🔸 Поисковые движки — быстрый фуллтекстовый поиск в больших объемах данных (Elasticsearch, OpenSearch).

🔸 Объектно-ориентированные БД — удобно для приложений на ООП-языках (Db4o).

🔸 RDF и векторные БД — для семантических и ИИ-задач: триплеты, эмбеддинги, смысловая близость.

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

#DBMS

смол ток😂)

🎯 Что такое INVEST и зачем оно нужно аналитикам?

INVEST — это удобная аббревиатура, которая помогает писать качественные пользовательские истории. Каждая буква обозначает важный критерий:

🔹 I — Independent (Независимая)
История не должна зависеть от других — так её проще приоритизировать и планировать.

🔹 N — Negotiable (Договорная)
История — это не контракт. Её можно переписать до начала разработки. Гибкость — наше всё.

🔹 V — Valuable (Ценная)
История должна приносить ценность пользователю, а не просто описывать внутреннюю реализацию.

🔹 E — Estimable (Оцениваемая)
История должна быть понятной и оцениваемой. Если нет — возможно, нужен технический «всплеск» (spike) для предварительного ресерча.

🔹 S — Sized Appropriately (Соразмерная)
Слишком большая история? Разбей. Слишком мелкая? Объедини. Главное — влезть в итерацию.

🔹 T — Testable (Тестируемая)
Формулировка истории должна позволять однозначно проверить, что сделано правильно.
❌ «быстро»
✅ «до 1,5 сек в 97% случаев»

🏷 #REQUIREMENTS

"ПРЫГУНОК"

Обсудить вопросы с командой)

🚀 Redis vs MongoDB: главное за 2 минуты

1. Модель данных
• Redis – in‑memory хранилище ключ‑значение, молниеносные операции, поддерживает структуры вроде списков, множеств и pub/sub ([Amazon Web Services][1]).
• MongoDB – документо‑ориентированная СУБД, хранит BSON-документы на диске, но может кешировать в памяти ([Amazon Web Services][1]).

2. Хранилище и производительность
• Redis работает в оперативной памяти, что обеспечивает минимальную задержку. Для устойчивости используют снапшоты и лог AOF ([Amazon Web Services][1], [Википедия][2]).
• MongoDB хранит данные на диске, допускает горизонтальное масштабирование и ACID‑транзакции ([Amazon Web Services][1]).

3. Масштабирование и отказоустойчивость
• Redis требует внешних компонентов (Sentinel, кластеры) для автоматического failover ([Википедия][3], [Amazon Web Services][1]).
• MongoDB из коробки поддерживает sharding и автоматическое переключение реплик ([Amazon Web Services][1]).

4. Язык запросов
• Redis — набор команд (GET, LPUSH и др.) для прямого доступа к ключам ([Amazon Web Services][1]).
• MongoDB — мощный JSON-подобный язык запросов MQL с поддержкой агрегатов и геоопераций ([Amazon Web Services][1]).

5. Когда что использовать
• Redis – идеален для кешей, сессий, real‑time очередей и подсчёта лидеров ([Википедия][2]).
• MongoDB – отлично подходит для документных хранилищ, профилей пользователей, геоданных и аналитики ([Amazon Web Services][1]).

✅ Часто используют их обе: Redis – как быстрый кэш/очередь, MongoDB – для долговечного хранения.

#DBMS

Никогда такого не было и вот опять)