ISEd. Просто об ИТ
248 subscribers
14 photos
1 video
1 file
25 links
📱💻Об ИТ-анализе и не только.
Download Telegram
Всем привет!
📌Вкину небольшое объявление.
Есть позиции для системных аналитиков (middle и выше), возможно совмещение (будешь получать 2 зарплаты). Если готовы рассмотреть - напишите в лс пожалуйста (@letyagod), лучше сразу с CV.
Коллеги, а сегодня праздник оказывается!
Каждый год, 24 сентября, отмечается день системного аналитика)📊

Всех поздравляем, желаем роста задач, компетенций и конечно же зарплат!
✍️По профильным чатам разлетается краткое содержание Вигерса, думаю, нам тут этот материал будет крайне полезен - забирайте!
Для тех, кто не знает - Карл Вигерс. "Разработка требований к программному обеспечению", это фактически настольная книга любого СА.
Правда очень объемная и скучная)
👨🏻‍💻Авторизация, Аутентификация, Идентификация - понятия, разницу между которыми должен понимать СА.

Идентификация:
Процесс определения, это пользователь или система. Это первый шаг, где пользователь предоставляет информацию, например, имя пользователя или адрес электронной почты.

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

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

✍️В качестве лайфхака, как легко различать эти понятия:
- идентификация — это "Кто вы?"
- аутентификация — это "Вы действительно тот, за кого себя выдаете?"
- авторизация — это "Что вам разрешено делать?".
ISEd. Просто об ИТ
Коллеги, подходим к концу года, поделитесь карьерными планами на 2025)💼
Спасибо всем, кто отметился!
💼Те, кто выбрал "Планирую выходить на рынок после НГ" и "Хочу вторую работу" - напишите мне в лс (@letyagod) пожалуйста, есть о чем поговорить)
Всем привет! Всех с полноценным началом рабочего года💼
Надеюсь, в 2025 году будет больше сил и времени на развитие нашего сообщества, очень в это верю и буду стараться.

💻А начать хотел бы с разговора об SQL — языке, который открывает двери в мир работы с базами данных.

SQL (Structured Query Language) — это мощный инструмент для управления данными.

Вот несколько причин, почему стоит изучать SQL:

1. Выборка данных: С помощью SQL ты можешь извлекать нужную информацию из базы данных, фильтровать, сортировать и объединять данные. Любые гипотезы, идеи, которые возникают во время работы с вашими системами, можно легко проверить, заглянув в БД.

2. Универсальность: SQL используется во многих системах управления базами данных, таких как MySQL, PostgreSQL, Microsoft SQL Server и других.

3. Подготовка к карьерным возможностям: Многие компании ищут специалистов, умеющих работать с SQL. Это может стать твоим козырем на рынке труда!

Так что если ты еще не начал изучать SQL, то самое время взяться за дело!

Для обучения рекомендую два материала:
1. Отличный Учебник (390 р/мес) - https://learndb.ru/
2. Бесплатный курс на stepik от ДВФУ https://stepik.org/63054

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

🟦 Основные отличия:

1. Когда используются:
- WHERE применяется для фильтрации строк до того, как они будут сгруппированы. То есть, он работает на уровне отдельных записей.
- HAVING, с другой стороны, используется для фильтрации групп после того, как они были созданы с помощью агрегатных функций (например, SUM, COUNT, AVG и т.д.) или же в связке с GROUP BY.

То есть, WHERE не поддерживает агрегатные функции, потому что он работает с индивидуальными записями, а HAVING может использовать агрегатные функции, так как он работает с результатами группировки.

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

     SELECT * FROM orders
WHERE amount > 100;

- Если же требуется получить только те группы клиентов, у которых сумма заказов превышает определенное значение, тогда используем HAVING:

     SELECT customerid, SUM(amount) AS totalamount
FROM orders
GROUP BY customer_id
HAVING SUM(amount) > 500;



☝️ Важный момент:
Если в запросе применяется и WHERE, и HAVING, то в синтаксисе SQL сначала должен выполняться WHERE, а потом HAVING.
Итак, давайте разберёмся с разницей операторов JOIN в SQL.
Базово, JOIN нужен для соединения таблиц.
В основном, у нас есть несколько основных типов JOIN:

1. INNER JOIN: Возвращает строки, которые имеют совпадения в обеих таблицах. Если в одной из таблиц нет соответствующей строки, то она не будет включена в результат.

2. LEFT JOIN (или LEFT OUTER JOIN): Возвращает все строки из левой таблицы и совпадающие строки из правой таблицы. Если в правой таблице нет совпадений, то вернутся NULL значения для её столбцов.

3. RIGHT JOIN (или RIGHT OUTER JOIN): Противоположен LEFT JOIN. Возвращает все строки из правой таблицы и совпадающие строки из левой. Если в левой таблице нет совпадений, то вернутся NULL значения для её столбцов.

4. FULL JOIN (или FULL OUTER JOIN): Возвращает строки, когда есть совпадение в одной из таблиц. Если строки не совпадают, то они всё равно будут включены, с NULL значениями в местах отсутствующих данных.

5. CROSS JOIN: Возвращает декартово произведение строк двух таблиц. Это значит, что каждая строка из первой таблицы будет соединена с каждой строкой из второй.

📌пара коварных вопросов, на которых пытаются подловить кандидата на собеседованиях:
1. Чем отличается INNER JOIN от просто JOIN?
2. В чем разница между LEFT/RIGHT/FULL OUTER JOIN и LEFT/RIGHT/FULL JOIN?
Ответ один - разницы нет!
🟦 Сравнение JSON и XML: разберемся.

В мире разработки веб-сервисов и API есть два наиболее популярных формата обмена данными: JSON (JavaScript Object Notation) и XML (eXtensible Markup Language). Каждый из них имеет свои особенности, преимущества и недостатки. Поехали.

◾️ 1. Формат и синтаксис

JSON:
- Легкий и читаемый формат, напоминающий JavaScript-объекты.
- Использует фигурные скобки для объектов и квадратные скобки для массивов.
- Пример JSON-объекта:

  {
"name": "Иван",
"age": 25,
"skills": ["JavaScript", "Python", "C++"]
}


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

  <person>
<name>Иван</name>
<age>25</age>
<skills>
<skill>JavaScript</skill>
<skill>Python</skill>
<skill>C++</skill>
</skills>
</person>



◾️ 2. Поддержка типов данных

JSON:
- Поддерживает несколько встроенных типов данных, таких как строки, числа, массивы и объекты.
- Не поддерживает атрибуты, как это делает XML.

XML:
- Позволяет создавать пользовательские теги и атрибуты.
- Может включать метаданные в виде атрибутов, что делает его более гибким.

◾️ 3. Производительность

JSON:
- Обычно быстрее в обработке, особенно в JavaScript, так как он легко преобразуется в объекты.
- Меньший объем данных по сравнению с XML, что делает его более эффективным для сетевых запросов.

XML:
- Может быть медленнее в обработке из-за своей структуры и необходимости парсинга тегов.
- Обычно занимает больше места из-за большого количества тегов.

❗️Одна и таже информация представленная в формате XML будет весить больше, чем в формате JSON.

🟦 Когда что применять?

- Используйте JSON, если вам нужно легковесное, быстрое и простое решение для обмена данными, особенно если вы работаете с JavaScript.

- Используйте XML, если вам нужна строгая структура данных, поддержка метаданных и возможность описания сложных документов.

В итоге, выбор между JSON и XML зависит от требований вашего проекта и предпочтений команды. Оба формата имеют свои сильные и слабые стороны, и понимание этих различий поможет вам сделать правильный выбор.
Раз уж в прошлом посте затронули XML, то стоит обсудить XSD — XML Schema Definition. Это язык, который используется для описания структуры и содержания XML-документов. Он помогает определить, какие элементы могут быть в XML-файле, их порядок, типы данных и другие ограничения.

Вот основные особенности XSD:

1. Валидация: XSD позволяет проверять, соответствует ли XML-документ заданной схеме. Это помогает избежать ошибок при обработке данных.

2. Типы данных: В XSD есть множество встроенных типов данных, таких как string, integer, date и другие, что дает возможность точно определить, какие данные могут быть в документе.

3. Структура: С помощью XSD можно задавать сложные структуры, включая вложенные элементы, атрибуты и их типы, обязательность, а также последовательность расположения элементов в XML-документе. Это делает схемы гибкими и мощными.

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

5. Совместимость: XSD является стандартом, поддерживаемым многими языками программирования и инструментами, что упрощает интеграцию и работу с XML.

Вот пример.

Есть следующая XSD-схема, описывающая структуру данных о студентах:

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="Students">
<xs:complexType>
<xs:sequence>
<xs:element name="Student" maxOccurs="unbounded">
<xs:complexType>
<xs:sequence>
<xs:element name="ID" type="xs:int"/>
<xs:element name="Name" type="xs:string"/>
<xs:element name="Age" type="xs:int"/>
<xs:element name="Major" type="xs:string"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>



🟦 Пример XML:

<Students>
<Student>
<ID>1</ID>
<Name>Иван Иванов</Name>
<Age>20</Age>
<Major>Программирование</Major>
</Student>
<Student>
<ID>2</ID>
<Name>Мария Петрова</Name>
<Age>22</Age>
<Major>Экономика</Major>
</Student>
<Student>
<ID>3</ID>
<Name>Алексей Смирнов</Name>
<Age>21</Age>
<Major>Филология</Major>
</Student>
</Students>
SOAP - а жив ли он?
SOAP (Simple Object Access Protocol) — это протокол для обмена структурированными данными в веб-сервисах. Он использует XML для передачи сообщений и обычно работает поверх HTTP. Основные плюсы SOAP — это высокая безопасность и возможность работы с различными языками программирования. Но есть и минусы: например, он может быть немного сложнее в настройке, чем REST.

❗️Основные понятия, в которых важно разобраться:
XML - формат сообщения.
XSD - схема сообщения.
WSDL - описание самомго SOAP-сервиса.

❗️Чем тестируют SOAP-сервисы:
Можно SOAP UI, а можно и Postman.

☝️И еще момент, часто можно встретить утверждение, что SOAP мало используется, потому что это очень "старый" протокол. Забавный факт, но REST моложе всего на 2 года)
Поэтому SOAP меньше используется не из-за возраста, а из-за того, что современные интеграции требуют большей пропускной способности и быстродействия - однако, в core-системах, где важна четкость данных, очень часто вы встретите именно SOAP.

Если хотите глубже разобраться с SOAP интеграциями, добро пожаловать на курс! До конца февраля скидка 23% по промо FEB.
Столкнулись с сокращениями в ИТ? (Вы, знакомые, коллеги в вашей компании)
Final Results
13%
Да, столкнулись
61%
Нет, во круг меня все ровно
26%
Нет, но есть ощущение, что в 2025 столкнусь
Хочется свериться по ощущениям у нас внутри.
«Сбер» начал увольнять айтишников «Купера», «Мегамаркета», «Сберлогистики» и «Самоката»

В СМИ и профильных отраслевых чатах разгорается дискуссия про волну сокращений в крупных IT-компаниях. Для кого-то это гром среди ясного неба, а для кого-то – логичное продолжение волны увольнений из крупнейших глобальных IT-компаний (в прошлые год-два из гигантов вроде Facebook, Twitter/X и т.д. сократили десятки тысяч людей, осенью 2024 сокращения прошли в VK).

Дорожание денег из-за роста ключевой ставки, плюс легкость раздувания штата в IT под ожидание гипер-роста через 5-10 лет, которые не оправдываются, плюс наводнение IT-джунами, прошедшими 3-6-9 месячные обучения очень высокого уровня, – все это, очевидно, разворачивает рынок труда в сторону работодателя.

Чего стоят только слова СЕО "Купера": Сотрудники, работающие менее пяти дней в неделю в офисе, считаются «неэффективными». Очень интересный тренд 🧐
Что такое REST?
Кажется, что уже давно всем известен ответ, однако до сих пор встречаю на консультациях и собеседованиях ответы, что REST - это некий протокол.

REST (Representational State Transfer) — это архитектурный стиль, который используется для создания веб-сервисов. Он позволяет различным системам взаимодействовать друг с другом через различные транспортные протоколы, чаще всего поверх HTTP.
RESTful API (программный интерфейс) используют стандартные методы HTTP, такие как GET, POST, PUT, PATCH и DELETE, для выполнения операций с ресурсами.

🟦 Основные принципы REST:

1. Клиент-серверная архитектура: Клиент и сервер независимо друг от друга. Клиент отправляет запросы, а сервер отвечает на них. Это позволяет разрабатывать и обновлять клиент и сервер независимо.

2. Отсутствие состояния (stateless): Каждый запрос от клиента к серверу должен содержать всю необходимую информацию для его обработки. Сервер не хранит информацию о состоянии клиента между запросами.

3. Кэшируемость: Ответы от сервера могут быть кэшированы, что позволяет снизить нагрузку на сервер и увеличить скорость работы приложения.

4. Единообразный интерфейс: REST предполагает использование стандартных методов HTTP и URI для взаимодействия с ресурсами. Это делает API более предсказуемым и удобным в использовании.

5. Слои системы: Архитектура может состоять из нескольких слоев, что позволяет разделять ответственность и повышать безопасность.

🟦 Преимущества REST:

- Простота: REST API обычно проще в использовании и понимании по сравнению с другими подходами, такими как SOAP,RPC,GraphQL и тд.
- Гибкость: Разные форматы данных (JSON, XML, Yaml - практичсекский любой формат) могут быть использованы для обмена информацией.
- Масштабируемость: REST позволяет легко масштабировать системы, добавляя новые сервера.

🟦 Заключение

REST — это мощный инструмент для создания веб-сервисов, который помогает разработчикам создавать гибкие и масштабируемые приложения.
❗️И запомните - это не протокол, а архитектурный стиль!
Давайте разберёмся с синхронным и асинхронным взаимодействием.

🟦 Синхронное взаимодействие

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


🟦 Асинхронное взаимодействие

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


🟦 Примеры применения

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

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

🟦 Технологии

В чистом виде, к синхронным способам взаимодействия можно отнести REST, SOAP и все остальные способы интеграции, основанные на подходе «запрос-ответ».
Тогда как асинхронное взаимодействие реализуется, например, посредством брокеров (RabbitMQ, Kafka и др), ESB.

☝️Однако, это НЕ означает, что невозможно получить асинхронный процесс взаимодействия при помощи REST, как и получить синхронный с помощью брокеров)
Как реализовать асинхронное взаимодействие с помощью REST. Это довольно распространённая задача, особенно в современных веб-приложениях, где важно не блокировать основной поток выполнения.

Вот несколько подходов к реализации асинхронного взаимодействия через REST:

🟦 Использование HTTP-заголовков: Один из простейших способов — использовать HTTP-заголовки для указания асинхронного характера запроса. Клиент делает запрос, и сервер может вернуть статус 202 Accepted, указывая, что запрос принят, но обработка ещё не завершена. Клиент может периодически опрашивать сервер для получения статуса выполнения задачи.

🟦Webhooks: Если сервер может отправлять уведомления клиенту, можно использовать webhooks. Когда задача завершена, сервер отправляет POST-запрос на заранее определённый URL клиента с результатами выполнения. Это позволяет избежать постоянного опроса и делает взаимодействие более эффективным.

🟦Polling (очень похож на п.1): Клиент может периодически отправлять запросы на сервер для проверки статуса выполнения задачи, и получает ответ 200 с бизнес-описанием статуса. Это также простой подход, но он может быть менее эффективным, так как генерирует лишний трафик. Тем не менее, он часто используется, когда другие методы недоступны.


🟦 Пример реализации:

1. Клиент отправляет запрос на создание задачи:

http
POST /tasks
Content-Type: application/json

{
"name": "Выполнить асинхронную задачу"
}

2. Сервер принимает запрос и отвечает:

HTTP/1.1 202 Accepted
Content-Type: application/json

{
"status": "accepted",
"taskId": "12345"
}


3. Клиент проверяет статус задачи:
http
GET /tasks/12345/status


4. Сервер возвращает статус:

HTTP/1.1 200 OK

Content-Type: application/json

{
"status": "in_progress"
}


4.1. После завершения задачи сервер может вернуть результат:

HTTP/1.1 200 OK

Content-Type: application/json

{
"status": "completed",
"result": "Задача выполнена"
}


Берите на вооружение!